SemVer Tester Diff

About this tool

SemVer Tester Diff parses and compares two semantic version strings using SemVer 2.0.0 precedence rules — major, minor, patch, pre-release identifiers, and build metadata. Type two versions and the tool validates both against the SemVer grammar, shows which one sorts higher, and classifies the difference as major, minor, patch, prerelease, or none. Quick-check buttons answer A == B, A > B, A < B, whether both versions are stable, and whether they are compatible (same non-zero major, no pre-release). Whether you are preparing a library release, reviewing a lock-file upgrade, or checking release-candidate order, this removes the hand-calculation and the subtle mistakes that come with pre-release comparison rules. Pre-release identifiers (alpha, beta, rc.1) are compared numerically or in ASCII order, and build metadata (+build.001) is ignored for ordering as per spec. The tool compares exact versions only; it does not evaluate npm range expressions. All parsing runs in-browser.

Why use it

• Precise diff classification: Instantly know whether two versions differ at the major, minor, patch, or pre-release level — no spec-reading required.

• Pre-release ordering done right: Pre-release strings follow SemVer ASCII/numeric precedence rules that are easy to mis-sort manually; the tool applies them correctly every time.

• Strict validation: Each version is checked against the SemVer 2.0.0 grammar, so typos, missing patch numbers or v-prefixed tags are flagged before you rely on them.

• Zero-install, browser-only: No Node.js, no semver npm package install needed. Type versions and get answers in milliseconds directly in your browser.

• Release workflow safeguard: Catch accidental version regressions or incorrect bump types before they reach a registry, changelog, or CI pipeline.

• One-click quick checks: Equality, greater-than, less-than, stability and same-major compatibility are each a single button press.

How to use

1. Type the first version string (e.g. 1.4.0-rc.1) into the Version A field.
2. Type the second version string (e.g. 1.4.0) into the Version B field — results update as you type, or click Compare.
3. Read the Ordering card (A < B, A = B or A > B) and the Diff Type card (major, minor, patch, prerelease or none).
4. Click a quick check — A == B, A > B, A < B, Compatible? or Both stable? — and read the true/false answer in the Quick Check card.
5. Check the Details box for both versions, their pre-release identifiers, and the diff classification.
6. Use Swap to reverse A and B, or Clear to start again.

When it helps

• Preparing an npm, PyPI, or Maven library release and needing to confirm the bump type matches the changes made.
• Reviewing a pull request that updates a lock file and wanting to understand whether a dependency upgrade is a major, minor, or patch change.
• Checking that a version string you plan to publish is valid SemVer before a CI release step rejects it.
• Comparing two release candidates (1.5.0-rc.1 vs 1.5.0-rc.2) and confirming pre-release ordering before promotion.
• Auditing a monorepo where multiple packages need coordinated versioning and manual comparison would be error-prone.
• Onboarding junior developers to SemVer rules by giving them an interactive tool to test their understanding of precedence.

Examples

Version A: 1.9.3  |  Version B: 2.0.0

Ordering: A < B
Diff Type: major

Version A: 1.2.3  |  Version B: 1.8.0  |  Compatible?

Ordering: A < B
Diff Type: minor
Quick Check: true

Version A: 2.0.0-rc.1  |  Version B: 2.0.0-beta.3

Ordering: A > B
Diff Type: prerelease

Tips

• Use the Compatible? check when reviewing a dependency bump: true means both versions are stable and share the same non-zero major, which is what a caret range like ^1.2.3 allows.
• When comparing 0.x.y versions, remember that even minor bumps can be breaking in zero-major packages; the Compatible? check returns false for any 0.x versions for this reason.
• Pre-release ordering trips up most developers: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0. Use this tool to verify chains of RC versions.
• Build metadata identifiers after + are useful for recording CI build numbers or commit hashes without affecting version ordering — safe to include in published tags.
• Strip the leading v from Git tags such as v2.1.0 before pasting — the parser accepts only plain SemVer strings.

Frequently Asked Questions

Glossary

Semantic Versioning (SemVer)

A versioning convention where a version number takes the form MAJOR.MINOR.PATCH, incrementing each segment based on the type of change: breaking (major), backwards-compatible feature (minor), or bug fix (patch).

Pre-release identifier

An optional hyphen-separated suffix on a SemVer string (e.g. -alpha.1, -rc.2) that designates an unstable build. Pre-release versions have lower precedence than the associated normal release.

Build metadata

An optional plus-sign-separated suffix (e.g. +build.001, +20231010sha) that records build provenance. It is ignored for ordering purposes per the SemVer spec.

Range expression

A string that describes a set of acceptable version values, using operators like ^, ~, >=, <, or hyphen ranges (1.0.0 - 2.0.0). Widely used in package.json and Cargo.toml dependency declarations.

Caret range (^)

An npm semver range operator that allows changes that do not modify the leftmost non-zero digit — ^1.2.3 resolves to >=1.2.3 <2.0.0, permitting minor and patch upgrades but blocking major bumps.

Tilde range (~)

An npm semver range operator that permits only patch-level changes when a minor version is specified — ~1.2.3 resolves to >=1.2.3 <1.3.0, making it stricter than the caret range.