Semver Checker & Version Comparator
Parse and compare SemVer 2.0.0 versions, name the change type, test them against an npm range like ^1.2.0, bump a version, and sort a list of them.
major: 1 minor: 2 patch: 0 prerelease: (none) build: (none)
major: 1 minor: 10 patch: 0 prerelease: (none) build: (none)
1.2.0 < 1.10.0Version A is lower than Version B
Change type: minor — backward-compatible feature
Written as in package.json: caret and tilde ranges, comparisons, x-ranges, hyphen ranges, and alternatives joined by ||.
Parse and compare semantic versions
Type two versions such as 1.2.0 and 1.10.0 and this tool instantly splits each one into its major, minor, patch, prerelease, and build metadata parts, then tells you which version wins by precedence and names the change type between them — major (breaking), minor (feature), patch (fix), a prerelease tag, or build-metadata only — so you can see at a glance whether an upgrade is breaking. When the higher of the two is itself a prerelease, as 2.0.0-alpha.1 is against 1.0.0, the change is named premajor, preminor or prepatch instead — a preview of the next release, not released yet — rather than a breaking change you can install today. It follows the official SemVer 2.0.0 grammar, so inputs like v1.2.3, 1.2, or a version with a leading zero such as 01.2.3 are flagged as invalid rather than silently accepted — but under the breakdown, “Did you mean this?” offers the strict version such an input most likely stands for, with a leading v dropped or the missing parts filled in, as a button that puts it in the field. Whenever the tidy form of a version differs from what was typed, a “Clean” line under its breakdown gives it as it belongs in package.json — no leading v, no surrounding spaces, no build metadata — with its own Copy button. Below the comparison, a Range field takes an npm range such as ^1.2.0, ~1.4.0, >=2.0.0 <3.0.0 or 1.2.x || 2.x, spells out what it means and says whether each version satisfies it; major, minor and patch buttons bump a version; and a list box sorts versions from lowest to highest. “⇄ Swap A and B” exchanges Version A and Version B in one step.
How precedence is decided
Major, minor, and patch numbers are compared numerically — which is why 1.10.0 is higher than 1.2.0 even though "2" looks larger as text. When those are equal, a prerelease version (like 1.0.0-alpha) ranks below the plain release (1.0.0). Prerelease identifiers are then compared field by field: all-digit fields numerically, everything else in ASCII order, with numeric fields ranking below non-numeric ones and a longer set of fields winning ties. Build metadata after the + sign is parsed for display but ignored when ranking, exactly as the spec requires.
Frequently asked questions
Why is 1.2.0 lower than 1.10.0?
Because semantic versioning compares each part as a number, not as text. Numerically 10 is greater than 2, so 1.10.0 has higher precedence than 1.2.0 even though '2' would sort after '1' as a string.
How are prerelease versions ranked?
A version with a prerelease tag is always lower than the same version without one, so 1.0.0-alpha is below 1.0.0. Two prerelease tags are compared identifier by identifier: numeric fields numerically, others in ASCII order, with numeric ranking below alphanumeric and a longer identifier list winning when everything else matches.
Can it check a version against a package.json range?
Yes. Type a range into Range the way package.json writes it — caret (^1.2.0), tilde (~1.4.0), comparisons (>=2.0.0 <3.0.0), x-ranges (1.2.x), hyphen ranges (1.2.3 - 2.3.4) and alternatives joined by || — and the page spells out the comparators it means and marks Version A and Version B as satisfying it or not, by node-semver's rules, including that a prerelease matches only a range that names a prerelease of the same release. Versions to sort, one per line, orders a list from lowest to highest and names the highest that satisfies the range.
Can it fix a git tag with a leading v, or a version missing its patch number?
Yes, as a suggestion. The strict reading stays, so such an input is still “Not a valid semantic version”, but under its breakdown “Did you mean this?” offers the version it most likely is: a leading v or = is dropped and the rest kept whole, prerelease included, or else the first run of numbers in it is read and the missing parts are filled in. Press the button to use it.
Why is 1.0.0 against 2.0.0-alpha.1 called a premajor, not a major?
Because 2.0.0-alpha.1 is not released yet: it is a preview of the next major. When the two versions differ in major, minor or patch and the higher one is a prerelease, the change type follows node-semver’s diff and says premajor, preminor or prepatch — “a preview of the next major, not released yet” — instead of calling it a breaking change you can install. Two prereleases of the same release, such as 1.1.0-rc.1 and 1.1.0-rc.2, are still a prerelease change.