UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

SemVer Tester Diff

Validate and compare semantic versions, including bump classification.

About SemVer Tester Diff

SemVer Tester Diff parses and compares semantic version strings using the full SemVer 2.0.0 precedence specification — major, minor, patch, pre-release identifiers, and build metadata. Paste two version strings and the tool instantly classifies the diff type (major, minor, patch, or pre-release), evaluates npm-style range expressions like ^1.2.3 and ~2.0.0, and shows which version sorts higher. Whether you are preparing a library release, auditing lock-file upgrades, or enforcing range policies in CI gates, this tool eliminates hand-calculation and the subtle mistakes that come with pre-release comparison rules. Pre-release identifiers (alpha, beta, rc.1) follow strict ASCII and numeric ordering — a detail that trips up manual checks. Build metadata (+build.001) is stripped from ordering as per spec. All parsing runs in-browser; nothing leaves your machine.

Why use SemVer Tester Diff

Precise diff classification

Instantly know whether two versions represent a breaking change (major), backwards-compatible feature (minor), or bug fix (patch) — 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.

Range expression validation

Test npm-style ranges like ^1.2.3, ~2.0.0, or >=3.0.0 <4.0.0 against any target version to verify dependency policy before a package.json update.

Zero-install, browser-only

No Node.js, no semver npm package install needed. Paste 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.

Shareable results

Copy the structured JSON result or bookmark the tool URL to share a consistent version-checking workflow with your team.

How to use SemVer Tester Diff

  1. Paste the first version string (e.g. 1.4.0-rc.1) into the Version A field.
  2. Paste the second version string (e.g. 1.4.0) into the Version B field and click Compare.
  3. Read the diff type badge — Major, Minor, Patch, or Pre-release — shown below the inputs.
  4. To test a range expression, type a semver range such as ^1.2.3 or >=2.0.0 <3.0.0 into the Range field.
  5. Enter a target version in the Test Version field and click Check Range to see if it satisfies the expression.
  6. Use the Copy button to copy the result JSON for pasting into CI scripts or release notes.

When to use SemVer Tester Diff

  • 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 transitive dependency upgrade is breaking or safe.
  • Writing CI version-gate scripts and needing to validate that range expressions like ^2.1.0 cover the installed version.
  • 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 range syntax.

Examples

Major version bump

Input: Version A: 1.9.3 | Version B: 2.0.0

Output: Diff type: MAJOR — Version B is higher. Breaking change expected.

Range compatibility check

Input: Range: ^1.2.3 | Test version: 1.8.0

Output: ✓ 1.8.0 satisfies ^1.2.3 (>=1.2.3 <2.0.0)

Pre-release ordering

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

Output: Diff type: PRE-RELEASE — Version A (rc.1) is higher than beta.3. Neither satisfies ^2.0.0.

Tips

  • Use the range tester to validate every dependency update in a PR before merging — paste the current semver range from package.json and the proposed new version to confirm compatibility.
  • When comparing 0.x.y versions, remember that even minor bumps can be breaking in zero-major packages; treat every 0.x increment as potentially major.
  • 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.
  • For monorepos with coordinated releases, paste versions of each package side-by-side to confirm all bumps are consistent and no package is accidentally left behind on an old version.

Frequently Asked Questions

What is the difference between ^ and ~ range operators?
The caret (^) allows changes that do not modify the leftmost non-zero digit — ^1.2.3 accepts >=1.2.3 <2.0.0. The tilde (~) allows only patch-level changes — ~1.2.3 accepts >=1.2.3 <1.3.0. For zero-major versions (^0.x.y), caret is stricter and only allows patch changes.
Does build metadata (e.g. +build.20231010) affect version ordering?
No. Per SemVer 2.0.0, build metadata is ignored for precedence and ordering. Two versions that differ only in build metadata are considered equal in rank. The tool strips it before comparison.
How are pre-release identifiers ordered?
Dot-separated identifiers are compared left to right. Numeric identifiers sort numerically; alphanumeric identifiers sort lexically in ASCII order. A version with a pre-release label always has lower precedence than the associated normal release: 1.0.0-rc.1 < 1.0.0.
Can I compare versions with v prefix like v1.2.3?
Yes. The tool strips a leading 'v' or 'V' before parsing, so v1.2.3 and 1.2.3 are treated identically. This matches the behavior of most registry tooling.
What happens if I enter an invalid version string?
The tool highlights the invalid field in red and displays a descriptive parse error. It will not attempt a comparison until both inputs are valid SemVer strings.
Is 0.x.y versioning handled correctly?
Yes. Zero-major versions are valid SemVer and the tool handles them correctly. Note that the npm ^ operator treats 0.x.y versions more conservatively — ^0.2.3 allows only >=0.2.3 <0.3.0 rather than <1.0.0.
Can I test versions against multiple ranges at once?
You can test one range expression at a time. For compound conditions, use space-separated comparators within a single expression: >=1.0.0 <2.0.0 is a valid combined range.
Is any version data sent to a server?
No. All parsing and comparison logic runs entirely in your browser using JavaScript. No version strings, ranges, or results are transmitted to any server.

Explore the category

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.