Parse, compare and increment semantic versions, and test whether a version satisfies an npm range like ^1.2.3 or ~1.2.3. Same semver library npm uses.
This semver calculator parses version strings, compares them under the real precedence rules, shows every possible increment of a version, and tests whether a version satisfies an npm range such as ^1.2.3 or ~1.2.3. It uses the same semver library that npm itself uses, so the answers match what your package manager will actually do. Everything runs in the browser — nothing is uploaded and no registry is contacted.
It exists because semantic versioning is deceptively simple. MAJOR.MINOR.PATCH is easy. What trips people up is the part underneath: whether 1.0.0-alpha.10 sorts before or after 1.0.0-alpha.9, whether build metadata affects precedence, and what exactly ^0.2.3 allows — which is not what most developers assume.
A semantic version is MAJOR.MINOR.PATCH, each a non-negative integer with no leading zeros, optionally followed by a prerelease identifier after a hyphen and build metadata after a plus sign:
1.2.3-beta.1+build.123
│ │ │ │ └─ build metadata (ignored for precedence)
│ │ │ └─────── prerelease identifier
│ │ └───────── PATCH — backwards-compatible bug fixes
│ └─────────── MINOR — backwards-compatible new functionality
└──────────── MAJOR — incompatible API changesThe rules that follow from this are strict. Increment MAJOR for any breaking change, and reset MINOR and PATCH to zero. Increment MINOR for backwards-compatible additions (and when functionality is marked deprecated), resetting PATCH. Increment PATCH only for backwards-compatible fixes. Once a version is published its contents must never change — a fix means a new version, always.
Version 0.y.z is explicitly special: anything may change at any time, and the public API is not considered stable. 1.0.0 is the moment you commit to a stable API, and that commitment is what the whole scheme is built on.
These are the rules people get wrong, and the ones the Comparator tab is most useful for.
A prerelease version has lower precedence than the release it precedes. So 1.0.0-alpha < 1.0.0. This is why publishing 2.0.0-beta.1 does not make it the target of a ^1.0.0 range and does not get installed by default.
Prerelease identifiers are compared field by field, dot-separated, left to right. Numeric identifiers compare numerically; alphanumeric identifiers compare as ASCII text; a numeric identifier always has lower precedence than an alphanumeric one; and a shorter set of fields loses to a longer one when all preceding fields are equal. That gives the canonical ordering from the specification:
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta
< 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0Note beta.2 < beta.11. Those fields are numeric, so they compare as numbers — unlike plain string sorting, where “11” would come before “2”. This is the single most common source of surprise in release tooling that sorts tags as strings.
Build metadata is ignored entirely for precedence. 1.0.0+build.1, 1.0.0+build.999 and 1.0.0 all have equal precedence. Metadata is for recording a commit hash or a build number; it is not a version bump, and a registry that treats two such versions as distinct is going beyond the specification.
Ranges are where semver meets dependency resolution. The Range tab expands any expression into its explicit bounds, but the common operators are worth knowing by heart:
| Range | Means | Expands to | Matches |
|---|---|---|---|
^1.2.3 | Compatible — no major change | >=1.2.3 <2.0.0 | 1.2.3, 1.4.0, 1.99.9 |
~1.2.3 | Approximately — no minor change | >=1.2.3 <1.3.0 | 1.2.3, 1.2.9 |
1.2.x | Any patch | >=1.2.0 <1.3.0 | 1.2.0, 1.2.7 |
1.x | Any minor and patch | >=1.0.0 <2.0.0 | 1.0.0, 1.8.2 |
1.0.0 - 2.0.0 | Hyphen range, inclusive both ends | >=1.0.0 <=2.0.0 | 1.5.0, 2.0.0 |
>=1.2.3 | Open upper bound | >=1.2.3 | 1.2.3 and anything later |
1.2.3 | Exact pin | =1.2.3 | 1.2.3 only |
The caret has a special case that catches everyone. For 0.x versions, ^ does not allow minor bumps, because under semver 0.x minor releases are permitted to break things. So ^0.2.3 expands to >=0.2.3 <0.3.0 — it behaves like a tilde — and ^0.0.3 expands to >=0.0.3 <0.0.4, an exact pin. If you have ever wondered why a ^0.x dependency never seems to update across minor versions, that is why.
A second subtlety: prereleases do not satisfy a range unless the range itself mentions a prerelease at the same major.minor.patch. 2.0.0-beta.1 does not satisfy ^1.0.0, and it does not satisfy >=1.0.0 either. To opt in you must write something like ^2.0.0-beta.1.
Starting from 1.4.2 with a prerelease tag of beta, the Incrementer tab produces all seven results at once:
major → 2.0.0
minor → 1.5.0
patch → 1.4.3
premajor → 2.0.0-beta.0
preminor → 1.5.0-beta.0
prepatch → 1.4.3-beta.0
prerelease → 1.4.3-beta.0The distinction between prerelease and the pre* forms is worth internalising: prerelease applied to a version that already has a prerelease tag bumps that tag’s counter (1.4.3-beta.0 → 1.4.3-beta.1), whereas applied to a clean release it bumps the patch and starts a new prerelease series.
If you are wiring version checks into a release pipeline, the regex tester is useful for validating tag patterns, the JSON formatter for inspecting a package.json or lockfile, and the cURL command builder for constructing the registry API calls that query published versions.
It allows any version that does not change the leftmost non-zero component. For ^1.2.3 that is >=1.2.3 <2.0.0. For ^0.2.3 it is >=0.2.3 <0.3.0, and for ^0.0.3 it is an exact pin.
The caret permits minor and patch updates; the tilde permits patch updates only. ^1.2.3 accepts 1.9.0; ~1.2.3 stops at 1.2.x.
Less. A prerelease always has lower precedence than the corresponding release version.
No. Everything after the + is ignored when comparing versions, so 1.0.0+abc and 1.0.0+xyz have equal precedence.
Because numeric prerelease fields are compared as numbers, not strings. Tooling that sorts version tags lexicographically will get this backwards.
Any time a change would break an existing consumer of your public API: removing or renaming an exported symbol, changing a signature, changing behaviour something depended on, or tightening validation that previously accepted an input. If a caller must change their code, it is a major bump.
Start at 0.1.0 while the API is still moving, then release 1.0.0 when you are willing to commit to stability. Do not stay on 0.x indefinitely for a package other people depend on in production — it deprives them of any compatibility guarantee.
No. A prerelease only satisfies a range that explicitly names a prerelease at the same major.minor.patch, so publishing a beta cannot break consumers on a stable range.
Not strictly — the specification does not include a v prefix — but the prefix is conventional on Git tags and most tooling, including this calculator’s coercion, strips it. Keep the prefix on tags if you like; do not put it in the version field of a manifest.
No. All parsing, comparison and range evaluation happen in your browser using the semver library bundled with the page.
Semantic Versioning (SemVer) is a versioning convention that communicates the nature of changes between software releases through a structured three-part version number: MAJOR.MINOR.PATCH. By following SemVer, package authors tell consumers exactly what to expect from an upgrade — whether it will break existing integrations, add new features, or fix bugs.
SemVer (semver.org) is the standard versioning scheme for npm, Cargo (Rust), Go modules, Composer (PHP), and most modern package ecosystems. Understanding SemVer is essential for managing dependencies, writing version constraints, and making informed upgrade decisions.
| Component | When to Increment | Example | Signal to Users |
|---|---|---|---|
| MAJOR (X.0.0) | Breaking changes to the public API | 2.0.0 → 3.0.0 | Code changes required to upgrade |
| MINOR (0.X.0) | New features, backward-compatible | 2.3.0 → 2.4.0 | New capabilities, existing code works |
| PATCH (0.0.X) | Bug fixes, backward-compatible | 2.4.1 → 2.4.2 | Safer to upgrade, existing code works |
| Format | Meaning | Example |
|---|---|---|
| 1.0.0-alpha | Pre-release: unstable, may change | Testing, early access |
| 1.0.0-beta.2 | Pre-release with iteration | Beta testing |
| 1.0.0-rc.1 | Release candidate | Final testing before stable |
| 1.0.0+build.123 | Build metadata (ignored in precedence) | CI/CD tracking |
| Syntax | Meaning | Accepts |
|---|---|---|
| ^1.2.3 | Compatible with 1.x.x | >=1.2.3, <2.0.0 |
| ~1.2.3 | Approximately 1.2.x | >=1.2.3, <1.3.0 |
| >=1.2.3 | Minimum version | 1.2.3 and above |
| 1.2.x | Any patch version | >=1.2.0, <1.3.0 |
| * | Any version | Everything |
Semantic Versioning is a versioning scheme that uses three numbers in the format MAJOR.MINOR.PATCH. Major version changes indicate breaking changes, minor version changes add new features that are backward compatible, and patch version changes indicate bug fixes. This system helps developers communicate the impact of updates clearly.
The caret (^) allows changes that do not modify the left-most non-zero digit, meaning it allows minor and patch updates but not major updates. For example, ^1.2.3 allows versions from 1.2.3 to less than 2.0.0. The tilde (~) allows only patch-level changes, so ~1.2.3 allows versions from 1.2.3 to less than 1.3.0.
Prerelease versions use suffixes like -alpha, -beta, or -rc followed by optional numbers (e.g., 1.0.0-beta.1). They indicate unstable versions still under development. Prerelease versions have lower precedence than the normal version, so 1.0.0-alpha comes before 1.0.0. Use them to distribute early versions for testing.
Version comparison follows a left-to-right precedence. First the major versions are compared, then minor, then patch. If these are equal, prerelease versions are compared alphabetically and numerically. Build metadata (after the + sign) is ignored in comparisons. For example, 2.0.0 is greater than 1.9.9 and 1.0.0 is greater than 1.0.0-beta.
Prerelease identifiers (after the hyphen) affect version precedence and indicate unstable releases. Build metadata (after the plus sign) provides additional information like build numbers or commit hashes but is completely ignored during version comparison. For example, 1.0.0+build.123 is equal to 1.0.0+build.456 in terms of precedence.
Enter a version range using npm-style syntax and a list of versions to test. The tool shows which versions satisfy the range and which do not. It also identifies the minimum and maximum satisfying versions. This is useful for understanding dependency resolution and checking package compatibility.
Increment MAJOR when you make incompatible API changes that require users to modify their code. Increment MINOR when you add functionality in a backward compatible manner. Increment PATCH when you make backward compatible bug fixes. Following these rules helps users understand the risk of updating to a new version.