What is Semantic Versioning (SemVer)?

Semantic Versioning is a widely adopted versioning scheme defined at semver.org. Version numbers take the form MAJOR.MINOR.PATCH, where MAJOR increments for breaking changes, MINOR for new backwards-compatible features, and PATCH for backwards-compatible bug fixes. Optional pre-release and build-metadata labels can follow after a hyphen or plus sign.

How does SemVer precedence work?

Versions are compared left to right: major first, then minor, then patch. If all three are equal, a pre-release version has lower precedence than the release version. Pre-release identifiers are compared identifier by identifier: numeric identifiers compare numerically, alphanumeric identifiers compare lexicographically, and a longer pre-release with an equal prefix is higher than a shorter one.

Is 1.0.0-alpha less than 1.0.0?

Yes. Per the SemVer specification, a pre-release version always has lower precedence than the associated normal version. So 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

Is build metadata included in version comparison?

No. Build metadata (the part after the + sign, e.g. 1.0.0+build.1) is ignored when determining version precedence. Two versions that differ only in build metadata are considered equal in terms of precedence.

Can I use this to compare npm, pip, or Cargo package versions?

If the package follows strict SemVer, yes. npm enforces SemVer for all packages in the registry. Cargo (Rust) also follows SemVer. Python (pip) uses PEP 440, which is similar but not identical: this tool may give unexpected results for PEP 440 pre-release labels like .post1 or .dev0.

What is the difference between a pre-release and a release candidate?

Both are pre-release versions (they have lower precedence than the release). The labels alpha, beta, rc, and release-candidate are conventional names. The SemVer spec does not assign special meaning to the text: it is just a string identifier. By convention: alpha is early and unstable, beta is feature-complete but potentially buggy, and rc (release candidate) is a build intended for final testing before release.

How do I know which version of a dependency to pin?

For production dependencies, pin to an exact version (e.g. 2.3.1) or use a tilde range (~2.3.1) to allow only patch updates. For development tools, a caret range (^2.3.0) to allow minor updates is common. This tool helps you verify that a candidate upgrade is truly a patch or minor bump before updating your lockfile.

Does the tool validate whether a string is a valid SemVer?

Yes. The tool checks each input against the official SemVer regex and shows an error for invalid strings such as v1.2, 1.2, or 1.2.3.4. Note that some ecosystems prefix versions with a v (e.g. v2.0.0): the tool strips that prefix before comparison.

Email Validator URL Validator IP Address Validator Color Validator SemVer Compare Kubernetes Linter

SemVer Comparison Tool

Q: Is build metadata included in version comparison?

No. Build metadata (the part after the + sign, e.g. 1.0.0+build.1) is ignored when determining version precedence. Two versions that differ only in build metadata are considered equal in terms of precedence.

Q: Can I use this to compare npm, pip, or Cargo package versions?

If the package follows strict SemVer, yes. npm enforces SemVer for all packages in the registry. Cargo (Rust) also follows SemVer. Python (pip) uses PEP 440, which is similar but not identical: this tool may give unexpected results for PEP 440 pre-release labels like .post1 or .dev0.

Q: What is the difference between a pre-release and a release candidate?

Both are pre-release versions (they have lower precedence than the release). The labels alpha, beta, rc, and release-candidate are conventional names. The SemVer spec does not assign special meaning to the text: it is just a string identifier. By convention: alpha is early and unstable, beta is feature-complete but potentially buggy, and rc (release candidate) is a build intended for final testing before release.

Q: How do I know which version of a dependency to pin?

For production dependencies, pin to an exact version (e.g. 2.3.1) or use a tilde range (~2.3.1) to allow only patch updates. For development tools, a caret range (^2.3.0) to allow minor updates is common. This tool helps you verify that a candidate upgrade is truly a patch or minor bump before updating your lockfile.

Q: Does the tool validate whether a string is a valid SemVer?

Yes. The tool checks each input against the official SemVer regex and shows an error for invalid strings such as v1.2, 1.2, or 1.2.3.4. Note that some ecosystems prefix versions with a v (e.g. v2.0.0): the tool strips that prefix before comparison.

Compare semantic versions, inspect breakdowns, and batch-sort version lists.

Version A

Version B

A < B

Field	Version A	Version B
major	1	1
minor	2	2
patch	3	4
prerelease	none	beta.1

Batch Sort (one version per line)

Free SemVer comparison tool: validate and compare semantic versions

Semantic Versioning gives teams a shared language for communicating the impact of a release: a patch bump means it's safe to update without reading the changelog, a minor bump adds functionality, and a major bump signals breaking changes. But comparing version strings by hand: especially when pre-release labels and build metadata are involved: is surprisingly tricky and easy to get wrong.

This tool implements the full SemVer 2.0.0 precedence algorithm. Paste two version strings and get an immediate, unambiguous answer about which is greater. You can also batch-sort a list of versions, which is useful when deciding which release to target for a hotfix or when auditing a dependency tree for outdated packages.

Step-by-step guide

1
Enter the first version
Type or paste a semantic version string such as 2.4.1, 3.0.0-alpha.1, or 1.2.3+build.456 into the first field.
2
Enter the second version
Add the version you want to compare against into the second field. Both fields validate format in real time.
3
View the comparison result
The tool immediately shows whether version A is greater than, less than, or equal to version B, using the SemVer precedence rules.
4
Check pre-release precedence
Pre-release versions (e.g. 1.0.0-alpha) are sorted below the release version (1.0.0). The tool applies the full identifier-by-identifier comparison defined in the SemVer spec.
5
Sort a list of versions
Switch to the batch mode, paste a newline-separated list of versions, and get them sorted in ascending or descending order.

Related Tools

✉️

Email Validator

Validate one or many email addresses at once. Regex-based checks with bulk input and copy-valid/invalid buttons.

🔗

URL Validator

Parse and validate URLs with protocol, hostname, port, path, query, and hash breakdown. Warns on HTTP.

🌐

IP Address Validator

Validate IPv4 and IPv6 addresses with CIDR support, classification badges, and binary display for IPv4.

🎨

Color Validator

Validate HEX, RGB, RGBA, HSL, and named colors. Live swatch preview and conversion to all formats.

Frequently Asked Questions

What is Semantic Versioning (SemVer)?: Semantic Versioning is a widely adopted versioning scheme defined at semver.org. Version numbers take the form MAJOR.MINOR.PATCH, where MAJOR increments for breaking changes, MINOR for new backwards-compatible features, and PATCH for backwards-compatible bug fixes. Optional pre-release and build-metadata labels can follow after a hyphen or plus sign.
How does SemVer precedence work?: Versions are compared left to right: major first, then minor, then patch. If all three are equal, a pre-release version has lower precedence than the release version. Pre-release identifiers are compared identifier by identifier: numeric identifiers compare numerically, alphanumeric identifiers compare lexicographically, and a longer pre-release with an equal prefix is higher than a shorter one.
Is 1.0.0-alpha less than 1.0.0?: Yes. Per the SemVer specification, a pre-release version always has lower precedence than the associated normal version. So 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
Is build metadata included in version comparison?: No. Build metadata (the part after the + sign, e.g. 1.0.0+build.1) is ignored when determining version precedence. Two versions that differ only in build metadata are considered equal in terms of precedence.
Can I use this to compare npm, pip, or Cargo package versions?: If the package follows strict SemVer, yes. npm enforces SemVer for all packages in the registry. Cargo (Rust) also follows SemVer. Python (pip) uses PEP 440, which is similar but not identical: this tool may give unexpected results for PEP 440 pre-release labels like .post1 or .dev0.
What is the difference between a pre-release and a release candidate?: Both are pre-release versions (they have lower precedence than the release). The labels alpha, beta, rc, and release-candidate are conventional names. The SemVer spec does not assign special meaning to the text: it is just a string identifier. By convention: alpha is early and unstable, beta is feature-complete but potentially buggy, and rc (release candidate) is a build intended for final testing before release.
How do I know which version of a dependency to pin?: For production dependencies, pin to an exact version (e.g. 2.3.1) or use a tilde range (~2.3.1) to allow only patch updates. For development tools, a caret range (^2.3.0) to allow minor updates is common. This tool helps you verify that a candidate upgrade is truly a patch or minor bump before updating your lockfile.
Does the tool validate whether a string is a valid SemVer?: Yes. The tool checks each input against the official SemVer regex and shows an error for invalid strings such as v1.2, 1.2, or 1.2.3.4. Note that some ecosystems prefix versions with a v (e.g. v2.0.0): the tool strips that prefix before comparison.

AlteredIdea vs alternatives

vs server-side tools: Everything runs in your browser: your data never leaves your device.

vs VS Code extensions: No install needed. Works instantly in any browser.

vs paid tools: Completely free, no account required.

Share:Share on X Share on LinkedIn