01
Separate versions from ranges
Versions require all three numeric parts. The range field accepts shorthand such as 1.2 and ^0.2.3. An empty range or empty OR branch is a wildcard.
Developer tools
Semver calculatorSee which versions actually match
Compare release precedence, test a dependency range or calculate the next version.
Semver calculator
Versions (one per line)
Your input is processed in this browser and is not sent to a server.
Result
Enter input or choose an example to begin.
Options
Exact SemVer 2.0.0 versions only: no surrounding spaces, v prefix or missing parts. Core numbers and numeric prerelease identifiers cannot have leading zeroes; build identifiers can.
npm range syntax accepts ^, ~, comparators, x, hyphen ranges and ||. Empty ranges and empty OR branches act as wildcards.
Prereleases are excluded unless a comparator in the same set names a prerelease with the same major.minor.patch.
Build metadata does not change precedence. Equal versions keep their input order when sorted.
Tool limits: 1,000 lines; 100,000 UTF-16 units; 256 characters per version; 4,096 per range. Core numbers and numeric prerelease identifiers must not exceed 9007199254740991. Build identifiers are not subject to this numeric limit.
Input or options changed. Refresh the results before exporting.
A Semver calculator helps when a beta appears newer yet does not match your dependency range. Compare precedence separately from range eligibility before changing a package constraint.
Use the semver range checker for a pasted list, or compare versions from two releases. Numeric ordering puts 1.10.0 after 1.9.0; plain text sorting can put them the other way around.
Why use this Semver calculator?
Explain an excluded beta
The Semver calculator shows the expanded npm range alongside each result. A version may satisfy the numerical bounds yet be excluded by the default prerelease rule.
Keep equal precedence visible
Sort versions without treating build labels as newer releases. 1.2.3+build.1 and 1.2.3+build.7 retain their original order because their precedence is equal.
Three details to check
02
Review the prerelease option
It starts off. Turning it on changes matching, not the strict version syntax. Read the expanded comparators, especially for ranges below 1.0.0.
03
Review replacements before applying
Example and Clear open a complete input/settings preview. Apply confirms it; Undo restores the previous state. Automatic mode waits 350 ms; manual mode supports Ctrl/Cmd+Enter.
Four release checks
Batch range matching
Test one version per line against npm comparators, caret, tilde, wildcards, hyphen ranges and OR groups.
Precedence comparison
Compare major, minor, patch and prerelease identifiers; build metadata never decides which is newer.
Stable list sorting
Sort ascending or descending. Invalid rows remain at the end with their original line numbers; equal precedence keeps its input order.
Seven increment types
Increment version numbers with major, minor, patch, premajor, preminor, prepatch or prerelease. Preview the result without changing the source version.
Syntax and practical limits
- Strict version strings
- Exact SemVer 2.0.0 versions only: no surrounding spaces, v prefix or missing parts. Core numbers and numeric prerelease identifiers cannot have leading zeroes; build identifiers can. Build metadata does not change precedence. Equal versions keep their input order when sorted.
- npm range semantics
- npm range syntax accepts ^, ~, comparators, x, hyphen ranges and ||. Empty ranges and empty OR branches act as wildcards. Prereleases are excluded unless a comparator in the same set names a prerelease with the same major.minor.patch.
- Bounded calculations
- Tool limits: 1,000 lines; 100,000 UTF-16 units; 256 characters per version; 4,096 per range. Core numbers and numeric prerelease identifiers must not exceed 9007199254740991. Build identifiers are not subject to this numeric limit.
- Release increments
- Increment removes build metadata. New prerelease counters start at 0. Leave the identifier empty to retain and increment the existing prerelease identifier.
- Local input, no installation
- No registry lookup, dependency installation or project editing takes place. Blank list rows are invalid; one final newline is only a terminator. A matching version does not prove API compatibility.
Semver calculator questions
What is the difference between ~ and ^ in package.json?
~1.2.3 allows stable versions from 1.2.3 below 1.3.0; ^1.2.3 extends below 2.0.0. Caret preserves the leftmost nonzero component: ^0.2.3 stops before 0.3.0 and ^0.0.3 before 0.0.4.
Does a caret range include the latest prerelease?
Normally no. The Semver calculator follows npm: with the option off, a comparator set must name a prerelease with the same major.minor.patch to admit it. Being the latest published version is irrelevant here.
What is build metadata for?
It can identify a build or commit, but it does not affect precedence. Versions differing only after + compare as equal; sorting preserves their input order.
Can I sort a mixture of version tag formats?
Only strict SemVer versions are sorted. Tags such as v1.2.3 or 1.10-alpine3 are reported as invalid and kept at the end. This tool does not coerce them into different strings.
How do I add an alpha suffix to a version?
Choose a pre-release increment and set the identifier to alpha. From 1.2.3, premajor gives 2.0.0-alpha.0. A prerelease increment can advance an existing counter; leave the identifier blank to retain it.
Unexpected version result?
Try the Semver calculator
Use the Semver calculator with your release list, inspect the range explanation, then save the current report.