Semver Compare

How to use it

1. Type the first version into Version A and the second into Version B — a v prefix is tolerated.
2. Both inputs update the comparison as you type, or press the compare button to re-run.
3. The verdict line shows A > B, A < B or A = B under SemVer precedence rules.
4. The table breaks both versions into major, minor, patch, prerelease and build metadata.
5. Try a prerelease pair (for example 2.0.0-beta.1 vs 2.0.0) to see why the full release ranks higher.

Common use cases

• Dependency reviews — decide whether an upgrade is a patch bump or a breaking change before merging.
• Release automation — sanity-check that a computed next version really is greater than the current tag.
• Version policy checks — confirm that prerelease identifiers like alpha.2 vs beta.1 order the way your docs claim.
• Teaching precedence — demonstrate that build metadata (+build.7) never affects ordering.

Why it stays private

The comparison runs with a local parser and a few comparisons in the browser. Neither version string is sent anywhere, so internal release tags are safe to paste.

FAQ

Q: Which rules does the comparison follow? A: SemVer 2.0.0: numeric major/minor/patch first, then prerelease identifiers compared segment by segment, where numeric identifiers rank below alphanumeric ones and a version without a prerelease outranks one with it. Build metadata is ignored for ordering.

Q: Are partial versions like 1.2 accepted? A: No. SemVer requires three numeric parts; inputs like 1.2 or 1 are rejected with an error rather than guessed, so the verdict always matches the spec.

Q: Why does 2.0.0 count as newer than 2.0.0-rc.1? A: Per the spec, a release candidate is a pre-release of that version, and any version with a prerelease has lower precedence than the associated normal version.