Loading the interactive tool… It runs in your browser — if it doesn't appear, enable JavaScript.
Compare two semantic versions and see which is newer, test whether a version satisfies an npm-style range, and get the next major, minor and patch. Precedence follows semver.org §11 exactly, including the parts most implementations get wrong.
Two of those parts cause real bugs. Build metadata is ignored entirely when comparing, so `1.0.0+a` and `1.0.0+b` have equal precedence. And a prerelease sorts *before* its release, so `1.0.0-alpha` is older than `1.0.0` — which is why npm won't install a prerelease for a normal range unless you ask for it explicitly.
Frequently asked questions
What's the difference between ^1.2.3 and ~1.2.3?
Caret allows changes that don't modify the leftmost non-zero digit — so ^1.2.3 permits anything below 2.0.0. Tilde allows patch-level changes only, so ~1.2.3 permits anything below 1.3.0. Caret is npm's default because semver promises minor releases are backwards compatible.
Why is ^0.2.3 so much tighter than ^1.2.3?
Because below 1.0.0 the leftmost non-zero digit is the minor version, so caret only permits patch updates — ^0.2.3 allows up to but not including 0.3.0. This is deliberate: semver treats 0.x as unstable, where a minor bump may break anything.
How do prerelease versions sort?
A version with a prerelease has lower precedence than the same version without one, so 1.0.0-rc.1 comes before 1.0.0. Within prereleases, identifiers are compared field by field: numeric ones compare numerically and always sort below alphanumeric ones, so 1.0.0-alpha.1 < 1.0.0-alpha.beta.
Does build metadata affect version ordering?
No. Everything after a + is ignored for precedence, so 1.0.0+build.1 and 1.0.0+build.99 are equal. That means you cannot use build metadata to release a newer version — package registries reject the duplicate.