Don't like ads? Go Ad-Free Today 

Semver Version Calculator & Range Tester

DataDeveloperText

ADVERTISEMENT · REMOVE?

INPUT

Auto Process

Operation

Pick the semver operation. The form fields below adjust automatically.

Version A

Strict SemVer 2.0.0 syntax — major.minor.patch[-prerelease][+build].

Version B

Compared against Version A with strict SemVer precedence.

Range

npm/composer-style range. Supports ^, ~, x, *, comparison operators, hyphen ranges, and ||.

Increment

Prerelease ID

Optional identifier for pre-* increments (e.g. alpha, beta, rc).

Versions

Each line is parsed as a version. Invalid lines are reported separately.

Sort Order

OUTPUT

Client Side

ADVERTISEMENT · REMOVE?

Guide

Semver Version Calculator & Range Tester

An all-in-one Semantic Versioning (SemVer 2.0.0) workbench for developers. Validate version strings, compare two versions with strict precedence, test whether a version satisfies an npm/Composer-style range expression (^, ~, x, hyphen, ||, comparison operators), bump a version with major/minor/patch/prerelease increments, and sort large lists of versions with full pre-release awareness — all client-side, with no installs required.

How to Use

Pick the operation you need from the Operation dropdown — Validate, Compare, Satisfies range, Increment, or Sort.
Fill in the version(s) and/or range field that the form reveals for that operation.
Read the result instantly — the tool shows a status summary, a per-component breakdown, and the canonical output you can copy or download.
For satisfies, the tool also shows how each comparator in your range was matched, so you can see exactly which clause accepted or rejected the version.

Features

Strict SemVer 2.0.0 validation – rejects leading zeros in pre-release identifiers, missing patches, malformed metadata, and other common slip-ups.
Two-version comparison – returns -1 / 0 / 1 with a human-readable verdict and a side-by-side breakdown of major, minor, patch, pre-release, and build.
Range satisfaction – supports caret (^1.2.3), tilde (~1.2.0), x-ranges (1.2.x), hyphen ranges (1.0.0 – 1.5.0), comparison operators (>=, <=, >, <, =), and OR (||).
Version increments – major, minor, patch, prepatch, preminor, premajor, and prerelease bumps with optional identifier (alpha, beta, rc).
Batch sort – paste one version per line, sort ascending or descending; invalid lines are reported separately so you can clean them up.
Pre-release precedence – follows the SemVer rule that pre-release versions are lower precedence than the associated normal version.
Build metadata aware – build metadata is parsed and displayed but ignored for precedence, exactly as the spec requires.
Copy and download – grab the result as text or a downloadable file with a single click.

 FAQ

What is Semantic Versioning (SemVer)?

Semantic Versioning is a public specification (semver.org) that gives software releases a meaningful three-part version number — MAJOR.MINOR.PATCH. MAJOR is bumped for breaking changes, MINOR for backwards-compatible features, and PATCH for backwards-compatible bug fixes. Optional pre-release tags (-beta.1) and build metadata (+sha.abc123) can be appended.
What does the caret (^) operator mean in a range?

^X.Y.Z accepts every version that does not change the leftmost non-zero component. ^1.2.3 means >=1.2.3 and =0.2.3 and =0.0.3 and <0.0.4. It is the default operator npm uses when you save a dependency.
How does the tilde (~) operator differ from caret?

~X.Y.Z is more conservative than ^. It allows patch-level changes only when MINOR is specified — ~1.2.3 means >=1.2.3 and =1.0.0 and <2.0.0).
How are pre-release versions compared?

Pre-release versions have lower precedence than the same normal version (1.0.0-alpha < 1.0.0). Identifiers are compared from left to right: numeric identifiers are compared numerically, alphanumeric ones lexically, and a smaller set of fields has lower precedence than a larger one.
Why is build metadata ignored when comparing versions?

The SemVer 2.0.0 specification states that build metadata (the +abc.123 suffix) MUST be ignored when determining version precedence. Two versions that differ only in build metadata are considered equal in ordering, even though they are not literally the same string.
Why does my pre-release version not satisfy ^1.2.0?

By npm's range-matching convention, a pre-release like 1.5.0-beta.1 only satisfies a range if at least one comparator in that range explicitly mentions a pre-release for the same MAJOR.MINOR.PATCH. This prevents pre-releases from accidentally leaking into normal-version ranges.