Semver Comparator - Compare Semantic Version Numbers

How to use this tool

1. Enter version A. Type or paste the first version number, e.g. 1.4.0.
2. Enter version B. Type or paste the second version number, e.g. 2.0.0-beta.1.
3. Compare. The result shows which version is greater, equal, or less.
4. Sort list. Paste multiple versions (one per line) into the Sort tab to order them.

What is Semantic Versioning?

Semantic Versioning (SemVer) defines a version number as MAJOR.MINOR.PATCH:

• MAJOR: Incompatible API changes. Users must update their code.
• MINOR: New backward-compatible features.
• PATCH: Backward-compatible bug fixes.

An optional pre-release label (-alpha.1, -beta.2, -rc.1) is appended after the patch. Build metadata (+sha.abc) is appended last and is ignored in comparisons.

Comparison rules

Versions are compared left-to-right: major, then minor, then patch. If all three match, pre-release fields are compared field-by-field, split by .. Numeric fields are compared numerically; alphanumeric fields are compared lexicographically. A release version always beats its pre-release counterpart.

Common version ranges (npm / semver)

• ^1.2.3: Compatible with 1.2.3 (same major)
• ~1.2.3: Approximately 1.2.3 (same major.minor)
• >=1.2.3 <2.0.0: Explicit range

Pre-release ordering pitfalls

Pre-release version ordering follows specific rules that often surprise developers. Here is the correct order for a single major version:

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

Key rule: a numeric pre-release identifier compares numerically (beta.2 < beta.11), while an alphanumeric identifier compares lexicographically. A numeric field also sorts before an alphanumeric field at the same position - which is why alpha.1 precedes alpha.beta.

Package manager range differences

The same range expression can mean different things across package ecosystems:

Why SemVer is often not followed

In practice, many libraries increment MINOR for changes that break some users' code when the authors feel the change is "small enough" or unlikely to affect real-world usage. Breaking changes sometimes ship as PATCH releases with the justification that the old behavior was a bug. SemVer is fundamentally a social contract between maintainers and consumers - it only works when both parties agree on what "breaking" means. When adopting a dependency, always review the changelog rather than relying solely on the version number.