Semantic Versioning Comparator

Package managers, changelogs, and release pipelines all lean on one quiet assumption: that 1.10.0 is newer than 1.9.9. String comparison gets that wrong, and so does every hand-rolled version check that splits on dots without parsing numbers. This comparator implements the full semver.org precedence rules, including prerelease field ordering and build-metadata exclusion, so your ordering matches what npm, Cargo, and every spec-compliant registry does.

Compare two versions side by side, test any version against caret, tilde, comparator, hyphen, and OR ranges, or paste a whole list and sort it by real semver order. Everything runs locally in the page.

How semver precedence is computed

Each version is parsed into five parts: major, minor, patch, an optional dot-separated prerelease list, and optional build metadata. Comparison walks the numeric triple first; the first non-equal component decides the order, which is why 1.10.0 beats 1.9.9 through integer comparison rather than string ordering.

When the triple is equal, build metadata is discarded and the prerelease lists are compared field by field. Numeric fields compare as numbers, mixed types sort with numbers first, and a shorter list loses when every shared field ties, because a release with more identifiers is considered further along its prerelease cycle. A version with an empty prerelease list (a stable release) always outranks any prerelease of the same triple.

Range satisfaction expands the expression into a set of comparators (greater-than, less-than, equals) and checks the candidate against all of them, with OR groups tried in sequence. Caret and tilde shorthands become an inclusive lower bound and an exclusive upper bound computed from the leftmost non-zero component, which is the same expansion node-semver performs.

Before and after: ordering a messy release list

Input — tags collected from a git repository, unsorted:

10.0.0
2.9.1
2.10.0
2.9.1-rc.2
2.9.1
1.0.0+build.7

Output — ascending semver precedence:

1.0.0+build.7
2.9.1-rc.2
2.9.1        (same triple as rc.2, stable outranks prerelease)
2.10.0       (minor 10 beats minor 9)
10.0.0       (major 10 beats major 2)
string sort would have placed 10.0.0 before 2.9.1

Who compares versions this way

Common mistakes when comparing versions

• Comparing versions as strings. Lexicographic order places 1.10.0 before 1.9.9 because the character 1 sorts below 9. Any gate that uses string greater-than on version numbers will block valid upgrades and allow invalid ones at random.
• Assuming prereleases satisfy caret ranges. npm refuses to install 2.0.0-rc.1 for a dependency declared as ^1.2.3 or ^2.0.0, because the range targets stable releases. If you want release candidates, declare them explicitly with a range that names the prerelease tuple.
• Forgetting that build metadata is ignored. Two artifacts tagged 1.4.0+sha.abc and 1.4.0+sha.def are the same version to every semver-aware tool. Deduplicate or rename at the registry layer rather than expecting consumers to distinguish them by precedence.
• Using tilde where caret was intended. ~1.2.3 never reaches 1.3.0, which surprises teams that expect npm default behavior. If minor updates should flow freely, write ^1.2.3 and let the range checker here confirm the bounds before you commit the manifest.

Best practices for version ranges in dependencies

• 1.Commit lockfiles so the resolved tree is pinned even when the manifest allows a wide caret range, giving you reproducible builds without giving up compatible updates.
• 2.Keep pre-1.0 libraries on tilde ranges; minors in that phase are allowed to break by the semver spec, so carets over-promise compatibility.
• 3.Use explicit comparator sets like >=1.4.0 <1.6.0 in shared infrastructure packages where a surprise minor from a caret range would ripple into every service at once.
• 4.Run the range tab here against the exact string you are about to publish, with your current version and the next planned release, so mistakes surface in review instead of in CI.

Frequently asked questions