SemVer Calculator: Validate, Sort and Test Version Ranges
Version strings do not sort like text or decimals: 1.10.0 is newer than 1.9.0, and 2.0.0-beta.10 is newer than 2.0.0-beta.2. This semver calculator applies the Semantic Versioning 2.0.0 rules to sort a list correctly, flags invalid versions, and shows which ones satisfy an npm-style range, so you can predict what npm install will pick before you change package.json.
What is semantic versioning?
A SemVer version is MAJOR.MINOR.PATCH, optionally followed by a prerelease tag (-beta.2) and build metadata (+build.5). You bump MAJOR for breaking changes, MINOR for new backward-compatible features and PATCH for fixes. The strict rules matter when parsing:
- All three numbers are required, so
1.2is not a valid version, although it is valid inside a range. - Numbers cannot have leading zeros:
01.2.3is rejected. - A leading
vis tolerated, as many Git tags use it. - A prerelease sorts before its release:
1.0.0-alpha < 1.0.0. - Numeric prerelease parts compare as numbers, and build metadata is ignored when comparing.
Example
With the range ^1.2.0:
Sorted (oldest first):
0.9.9 ✘ outside ^1.2.0
1.0.0-alpha ✘ outside ^1.2.0
1.2.3 ✔ satisfies ^1.2.0
1.2.10 ✔ satisfies ^1.2.0
1.10.0 ✔ satisfies ^1.2.0
2.0.0-beta.2 ✘ outside ^1.2.0
2.0.0-beta.10 ✘ outside ^1.2.0
2.0.0 ✘ outside ^1.2.0
Range ^1.2.0 → >=1.2.0 <2.0.0-0
Highest matching version: 1.10.0
Next versions after 2.0.0: patch 2.0.1 · minor 2.1.0 · major 3.0.0 · prerelease 2.0.1-0The expanded range line shows exactly what the shorthand means, and "Highest matching version" is the one a package manager would install from that list. The last line suggests the next patch, minor, major and prerelease numbers after the newest version.
Range syntax explained
| Range | Means |
|---|---|
^1.2.3 | >=1.2.3 <2.0.0-0: anything without a breaking change |
^0.2.3 | >=0.2.3 <0.3.0-0: in 0.x, the minor version counts as breaking |
~1.2.3 | >=1.2.3 <1.3.0-0: patch updates only |
1.2.x or 1.2 | >=1.2.0 <1.3.0-0 |
1.2.3 - 2.3 | >=1.2.3 <2.4.0-0 (hyphen range) |
1.x || >=3.0.0 | either set matches |
* | any release version |
Prereleases and ranges
npm deliberately keeps betas out of ranges. A prerelease such as 1.3.0-beta.1 only satisfies a range if a comparator in the same set names a prerelease of the same major.minor.patch. So ^1.2.3-beta.1 matches 1.2.3-beta.2 but not 1.3.0-beta.1. Tick Include prereleases in ranges to drop that rule, which matches npm's includePrerelease option.
Common range mistakes
- No upper bound.
>=1.0also accepts 2.0.0 and every future breaking release. Add<2or use a caret. - Expecting a bare version to float.
1.2.3matches exactly that version and nothing else. Use a lockfile, not exact pins, for reproducible installs.
Comparing two versions
Compare first two prints the relation between the first two valid versions and the level of difference, for example 2.0.0-beta.10 > 2.0.0-beta.2 with "Difference: prerelease". It is handy for deciding whether an upgrade is major, minor or a patch.
To read the dependencies block you are checking, open your package.json in the JSON validator. If you need a pattern that matches version strings in logs or CI scripts, build it in the regex tester.
Privacy
Parsing, sorting and range matching run in your browser. No registry is contacted and your version lists stay on your machine.