Semver tools — compare versions, test npm ranges and preview bumps

Enter one or two version numbers and an npm-style range, and the tool validates them against SemVer 2.0.0, says which version has higher precedence, tells you whether each satisfies the range, spells the range out as plain comparators and lists the next version for every bump type.

Live demo · real result from this tool
npm syntax: ^1.2.0, ~1.4, >=1.0.0 <2, 1.x, 1.2.3 - 2.0.0, a || b
Comparison1.4.2 < 2.0.0-rc.1
Newer
2.0.0-rc.1
Range ^1.2.0 means
>=1.2.0 <2.0.0-0

Satisfies ^1.2.0

VersionSatisfies
1.4.2yes
2.0.0-rc.1no

Parsed

VersionMajorMinorPatchPrereleaseBuild
1.4.2142——
2.0.0-rc.1200rc.1—

Next versions after 1.4.2

BumpResult
major2.0.0
minor1.5.0
patch1.4.3
premajor2.0.0-rc.0
preminor1.5.0-rc.0
prepatch1.4.3-rc.0
prerelease1.4.3-rc.0

Processed on your device — nothing is uploaded.

How to use the semver tools

  1. Type Version A, for example the version you have installed.
  2. Optionally type Version B to compare. Leave it empty to check A alone.
  3. Type a Range in npm syntax: ^1.2.0, ~1.4, >=1.0.0 <2, 1.x, 1.2.3 - 2.0.0, or several joined with ||.
  4. Set Prerelease identifier for bumps, such as rc, beta or alpha.
  5. Read the comparison, what the range means, whether each version satisfies it, the parsed parts and the bump table.

What it does and when to use it

Version numbers drive dependency installs, release tooling and update checks, and small details matter: is 1.0.0-alpha.10 newer than 1.0.0-alpha.9? Will ^0.3.1 pull in 0.4.0? Use this page when a lockfile picks a version you did not expect, when you write a peer-dependency range, or when you decide the next release number.

For writing the changelog commit that goes with a release, the Conventional Commit Generator helps, and the Git Cheatsheet lists the git tag commands.

How it works

Versions are checked against the SemVer 2.0.0 grammar: three numbers without leading zeros, an optional -prerelease and an optional +build. Precedence follows section 11 of the spec. Numbers compare numerically, a version with a prerelease is lower than the same version without one, and prerelease parts compare one by one, with numeric parts lower than text parts.

Ranges are expanded the way npm’s node-semver does, into sets of comparators joined by ||. The tool reimplements those rules rather than loading the npm package, and runs in your browser.

Worked examples

A 0.x caret range. A 0.3.7, B 0.4.0, range ^0.3.1:

Comparison: 0.3.7 < 0.4.0
Range ^0.3.1 means: >=0.3.1 <0.4.0-0
0.3.7 | yes
0.4.0 | no

A prerelease and a plain range. A 2.1.0-beta.2, B 2.1.0, range >=2.0.0, identifier beta. The result is 2.1.0-beta.2 < 2.1.0; the beta shows 2.1.0-beta.2 | no and the release yes. The bump table gives prerelease | 2.1.0-beta.3, while minor and patch both give 2.1.0, because releasing a prerelease drops the tag.

An invalid version. A 1.4 returns: “all three numbers are required (MAJOR.MINOR.PATCH)”. Ranges accept partial versions like 1.4; exact versions do not.

Limits and tips

  • npm options such as includePrerelease and loose parsing are not available.
  • Only SemVer is understood. Python (PEP 440), Maven and calendar versions follow other rules.
  • To compare two package.json files line by line, use the Diff Checker.

Frequently asked questions

What is the difference between ^ and ~?
Caret allows changes that do not touch the left-most non-zero number, so ^1.2.3 means >=1.2.3 <2.0.0-0. Tilde allows patch changes only when a minor is given, so ~1.2.3 means >=1.2.3 <1.3.0-0.
Why does ^0.3.1 stop before 0.4.0?
Below 1.0.0 the minor number acts like a major one, so npm treats 0.3 to 0.4 as a breaking change. ^0.0.3 is even stricter and matches 0.0.3 only.
Why does a beta version fail a range it seems to be inside?
npm's prerelease rule. 2.1.0-beta.2 is above 2.0.0, but a prerelease only satisfies a range when some comparator in it names the same major.minor.patch with a prerelease tag. >=2.1.0-beta.0 would match it.
Is v1.2.3 valid?
The leading v is accepted and ignored, as npm does. Strictly, SemVer 2.0.0 does not include the v, so leave it out of package.json versions.
Does build metadata change the order?
No. 1.2.3 and 1.2.3+build.5 have the same precedence. The tool shows them as equal and lists the build part in its own column.

Written by the ToolsRift team · Last updated

Pages are drafted with AI assistance and checked by automated tests. How we write and check pages.

Was this tool useful?

Report a problem

Start typing to search every tool.

↑ ↓ to moveEnter to openEsc to close