Test versions against an npm range such as ^1.2.3, sort them and see the next version
Runs in your browser. Nothing you type is sent anywhere. Checked against sources on 16 Oct 2026.A semver range lists the versions a package accepts. In npm, ^1.2.3 means at least 1.2.3 and below 2.0.0, while ~1.2.3 stops below 1.3.0. Below version 1, the caret is stricter, so ^0.2.3 stops below 0.3.0. A pre-release such as 1.3.0-beta matches only a range naming a 1.3.0 pre-release.
Type the range from package.json, such as ^1.2.3 or >=18 <21, in the Range box.
Paste the versions to test, one per line, or click Try an example.
Read the list: each version is marked as matching or not, sorted lowest first, with the highest match named.
Click Copy to take the sorted list, or Copy matching for only the versions in range.
Semantic Versioning writes a release as MAJOR.MINOR.PATCH: a major change may break code that uses it, a minor one adds features, and a patch only fixes bugs. Package managers rely on that promise when they read a range such as ^1.2.3 in package.json and pick the newest version that fits.
Type a range and paste versions, one per line. Each version is marked as inside or outside the range, the list is sorted in true version order, and the highest and lowest matches are named. The range is also written out as plain comparators, exactly as npm prints it, so ^0.2.3 shows as >=0.2.3 <0.3.0-0.
| Range | Means | Example match |
|---|---|---|
^1.2.3 |
>=1.2.3 <2.0.0 | 1.9.4 |
^0.2.3 |
>=0.2.3 <0.3.0 | 0.2.9 |
~1.2.3 |
>=1.2.3 <1.3.0 | 1.2.10 |
1.x |
>=1.0.0 <2.0.0 | 1.4.0 |
1.2.3 - 2.3 |
>=1.2.3 <2.4.0 | 2.3.9 |
>=18 <21 |
18.0.0 up to below 21.0.0 | 20.11.1 |
Ordering. Numbers compare as numbers, so 1.10.0 is newer than 1.9.0. A pre-release sorts below its release: 2.0.0-rc.1 comes before 2.0.0. Inside a pre-release, numeric parts compare numerically and sort before words, so beta.2 is below beta.11 and 1 is below alpha. Build metadata after a plus sign never changes the order.
Mistakes explained. A line that is not a version says why: 1.2 is missing its patch number, 01.2.3 has a leading zero, and 1.2.3.4 has a part too many. Where the fix is obvious, it is suggested.
Next versions. For the highest version in the list, the next major, minor, patch and pre-release are shown, as npm version would write them.
Every answer is checked against node-semver, the library npm itself uses, over more than 3,000 comparisons and 100 ranges. Everything runs in your browser; nothing you paste is sent anywhere.
A tilde allows patch updates only: ~1.2.3 accepts 1.2.4 and 1.2.10 but not 1.3.0. A caret also allows minor updates: ^1.2.3 accepts everything below 2.0.0. Since npm writes a caret by default, most projects take new features automatically and stop only at the next major version.
Below 1.0.0, npm treats the first non-zero number as the major version, because the API is not yet stable. So ^0.2.3 means at least 0.2.3 and below 0.3.0, and ^0.0.3 allows only 0.0.3 itself. Moving a package to 1.0.0 is what turns on the wider caret range.
Yes. Each part of a semantic version is compared as a whole number, so a minor version of 10 is greater than 9. Sorting version numbers as text, or reading them as decimals, puts 1.10.0 before 1.9.0, which is wrong. Paste both here to see the correct order and which part differs.
No. A pre-release only matches a range that names a pre-release of the same major, minor and patch numbers. So 1.3.0-beta matches >=1.3.0-alpha but not ^1.2.3, even though it sorts inside that range. Pre-releases stay out of normal installs unless you ask for them.
A pre-release comes before its release, so 1.0.0-rc.1 is older than 1.0.0. Pre-release parts are compared one dot-separated part at a time: numbers numerically, words alphabetically, and numbers before words. The Semantic Versioning example order is alpha, alpha.1, alpha.beta, beta, beta.2, beta.11, rc.1, then the release.
Everything after a plus sign is build metadata, such as 1.0.0+20261016 or 1.0.0+sha.5114f85. Build metadata identifies a particular build but is ignored for ordering, so 1.0.0+a and 1.0.0+b count as the same version. Ranges ignore it too, and npm drops it when printing a range.
Rates and rules change; check the source before you rely on a figure.
Still stuck? Ask about Semver Checker and anybody who knows can answer. No account needed.
Same job, other tools: HTTP 401 Unauthorized – The code for a failed login or an expired token, and the header it must carry · HTTP 403 Forbidden – The difference between 403 and 401, and when a 404 is the safer reply.
On the related tools: Readability Checker – Flesch reading ease and grade level, with what to change.