SemVer Comparator
Compare semantic version strings and check range compatibility.
Backwards-incompatible breaking change. Consumers must update their integration codebase.
1.2.3 is less than 2.0.0-beta.1
Component Breakdown
Supports ^, ~, >=, <=, >, <, =. Space = AND, || = OR.
Understanding Semantic Versioning
Semantic Versioning (SemVer) is a versioning scheme defined at semver.org. A version number takes the form MAJOR.MINOR.PATCH: the major version increments for breaking changes, minor for backwards-compatible new features, and patch for backwards-compatible bug fixes. An optional pre-release label (e.g. -beta.1) identifies unstable builds; a stable release always beats a pre-release of the same MAJOR.MINOR.PATCH. The caret range ^ allows minor and patch updates for a given major; the tilde range ~ allows only patch updates for a given major.minor. Everything runs locally in your browser.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Checking whether one version satisfies a declared range.
- Comparing two versions where prerelease tags make the ordering unobvious.
- Working out whether an upgrade is a breaking change by the numbering.
- Checking a caret or tilde range's actual bounds.
- Confirming a dependency resolution you did not expect.
Frequently Asked Questions
- How does 1.0.0-alpha compare with 1.0.0?
- It is LOWER. A version with a pre-release identifier always precedes the same version without one — that is spec §11 — because a pre-release is a release candidate for it. So 1.0.0-alpha < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0, which is exactly the order you would want.
- How are pre-release identifiers ordered?
- Field by field, dot-separated. Numeric identifiers compare numerically, so alpha.2 < alpha.10 — not the string ordering that would put 10 first. A numeric identifier always ranks below an alphanumeric one, and a shorter list of otherwise equal fields ranks lower.
- Does build metadata affect ordering?
- No — everything after `+` is ignored entirely for precedence, so 1.0.0+build1 and 1.0.0+build999 are EQUAL versions. It exists to record a build without creating a new release, which is also why a package registry will not let you publish both.
- What do ^ and ~ actually allow?
- `^1.2.3` allows anything below 2.0.0 — minor and patch updates. `~1.2.3` allows anything below 1.3.0 — patch only. The exception catches people: for 0.x versions `^` behaves like `~`, because 0.x is defined as unstable and a minor bump there may break things.
- Why is 1.02.3 invalid?
- Because leading zeros are forbidden in the numeric fields — the grammar is `0|[1-9]\d*` per part. It keeps the version's string form and its numeric meaning in one-to-one correspondence, so 1.02.3 and 1.2.3 cannot exist as two distinct spellings of one release.
Common errors and gotchas
- Comparing versions as strings, where 1.10.0 sorts before 1.9.0.
- Assuming a prerelease sorts above its release, when 1.0.0-rc.1 comes before 1.0.0.
- Misreading a caret range below 1.0.0, where it behaves like a tilde rather than allowing minor bumps.
- Treating build metadata as part of the ordering, which it is not.
- Assuming a major bump means breaking, which only the project's own discipline guarantees.