🔢 Semantic Versioning Calculator
Runs entirely in your browser - no data sent to server
Output appears here...
📊 Key Data Points
^MAJOR.x.x
Caret ranges allow minor and patch updates but lock the major version
~MAJOR.MINOR.x
Tilde ranges allow only patch updates within the specified minor version
semver.org
The semantic versioning specification — defines the rules this calculator implements
Semver Calculator — Semantic Version Range Tester -- Complete USA Guide 2026
Semantic versioning ranges in package.json, Cargo.toml, and go.mod control which versions of a dependency your project will install. A misunderstood range like ^1.2.3 or ~1.2.3 can install an unexpected major or minor version that breaks your build.
This calculator tests semver ranges against version lists, shows which versions match, and explains each range specifier. Runs in your browser.
**Long-tail searches answered here:** what versions does ^1.2.3 match in npm, difference between ~ and ^ in package.json semver, semver range tester online free.
For managing package files, pair with Package JSON Generator.
🔬 How This Calculator Works
Semantic versioning defines three numbers: MAJOR.MINOR.PATCH. MAJOR changes indicate breaking changes; MINOR changes add backward-compatible features; PATCH changes are backward-compatible bug fixes.
Range specifiers: ^1.2.3 (caret) matches >=1.2.3 and <2.0.0 — allows minor and patch updates but not major. ~1.2.3 (tilde) matches >=1.2.3 and <1.3.0 — allows only patch updates.
The calculator tests your range against a list of version strings and highlights which ones match.
✅ What You Can Calculate
Range vs version list matching
Enter a range like ^1.2.3 and a list of versions to see exactly which ones match. Eliminates the guesswork in understanding what ^ and ~ actually select.
^ vs ~ comparison
Side-by-side comparison shows that ^1.2.3 matches 1.3.0 and 1.4.0 (minor updates) while ~1.2.3 matches only 1.2.4 and 1.2.5 (patch updates only).
Pre-release version handling
Shows how pre-release versions (1.2.3-alpha.1, 2.0.0-beta.2) interact with ranges — pre-release versions are excluded from ranges unless explicitly specified.
Version bump simulator
Enter your current version and select the change type (major/minor/patch/pre-release) to see the correct next version number.
🎯 Real Scenarios & Use Cases
Debugging npm install results
Your package.json has react ^18.0.0 but you want to understand exactly which React versions could be installed. Test the range against available versions here.
Planning breaking change releases
You are releasing a breaking change. Verify that incrementing the major version will cause ^1.x.x ranges in dependent packages to exclude your new version.
Cargo.toml version constraints
Rust Cargo uses semver with slightly different range syntax. Test your Cargo.toml version constraints here to verify they allow the versions you intend.
Monorepo package version alignment
In a monorepo, internal packages reference each other with exact or range versions. Verify that all internal references resolve to the correct local package versions.
💡 Pro Tips for Accurate Results
Use ~ for patch-only updates in production. For stability-critical production dependencies, use ~1.2.3 (patch updates only) rather than ^1.2.3 (minor updates allowed). Minor versions can introduce behavioral changes.
^0.x.x is not the same as ^1.x.x. For versions below 1.0.0, ^0.2.3 only allows patch updates (not minor) because pre-1.0 minor versions are considered potentially breaking.
Pre-release versions require explicit opt-in. ^1.2.3 does not match 1.3.0-beta.1 — pre-release versions are excluded unless you explicitly specify >=1.2.3-beta.0 <2.0.0.
Lock files are your actual protection. Semver ranges define what CAN be installed; your package-lock.json or yarn.lock defines what IS installed. Always commit lock files.
🔗 Use These Together
🏁 Bottom Line
Semver range syntax has non-obvious edge cases — especially around pre-1.0 versions, pre-release tags, and the difference between ^ and ~. This calculator makes the matching behavior concrete by testing ranges against real version lists.
For the full package management workflow: test ranges here, generate package.json with Package JSON Generator, and search available versions with npm Package Search.
What does semantic versioning (semver) mean?
Semantic Versioning (semver.org) uses three numbers MAJOR.MINOR.PATCH with specific meanings: MAJOR increments on breaking changes (API incompatible with previous version). MINOR increments when new backwards-compatible features are added. PATCH increments for backwards-compatible bug fixes only. Pre-release versions: 1.0.0-alpha.1, 1.0.0-beta.2, 1.0.0-rc.1. Build metadata: 1.0.0+build.123 (ignored in comparisons). Following semver allows consumers of a library to safely specify version ranges — they know a ^1.x.x update will not break their code.
What is the difference between ^ (caret) and ~ (tilde) version ranges?
Caret (^): allows changes that do not modify the leftmost non-zero number. ^1.2.3 accepts >=1.2.3 <2.0.0 (any 1.x.x at or above 1.2.3). ^0.2.3 accepts >=0.2.3 <0.3.0 (minor version is leftmost non-zero). ^0.0.3 accepts exactly 0.0.3. Tilde (~): allows patch-level changes only. ~1.2.3 accepts >=1.2.3 <1.3.0. ~1.2 accepts >=1.2.0 <1.3.0. ~1 accepts >=1.0.0 <2.0.0. Caret is more permissive — it allows minor updates. Tilde is more conservative — only patch updates. npm's default when you install a package is the caret range.
Why does ^0.x.x behave differently from ^1.x.x?
Semver treats 0.x.x versions specially: the major version 0 is for initial development where anything may change at any time. Therefore, the caret restricts more aggressively: ^0.2.3 means >=0.2.3 <0.3.0 (not <1.0.0), because in a 0.x.x package, even minor version bumps may be breaking. ^0.0.3 is even stricter: exactly 0.0.3 only. This reflects reality — packages in major version zero are explicitly declaring they make no stability guarantees. Once a package reaches 1.0.0, the caret range becomes the standard >=1.x.x <2.0.0 behavior.
What does 'latest' mean in package.json and why is it dangerous?
latest is a dist-tag pointing to the most recently published version. Using 'latest' as a version in package.json is not a semver range — it resolves to whatever is tagged latest at install time. This is dangerous: a major breaking update that someone publishes as latest will silently update all dependents using 'latest', breaking their applications. Always use a semver range (^1.2.3 or ~1.2.3) or exact version (1.2.3) in production package.json. 'latest' is appropriate only for global tool installs: npm install -g typescript@latest.
How do pre-release versions interact with semver ranges?
By default, semver ranges do not include pre-release versions unless the range specifically mentions a pre-release. ^1.2.3 does NOT match 1.3.0-beta.1 even though beta.1 is technically between 1.2.3 and 1.3.0. To include pre-releases: ^1.2.3-0 or >=1.2.3 includes pre-releases above 1.2.3. When publishing a pre-release to npm: npm publish --tag beta prevents it from being installed as 'latest' — users must explicitly opt in with @beta tag.
What is the difference between package.json version ranges and lockfile versions?
package.json specifies ranges: ^1.2.3. The lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) records the exact version resolved at install time: 1.4.7. Future installs on the same machine use the lockfile version (1.4.7), not re-resolving the range. npm install on a new machine without a lockfile resolves the range to the highest matching version available at that moment. Commit your lockfile to version control so all team members and CI use identical dependency versions.
What other package tools are on this site?
The npm Package Search finds packages and shows their latest versions and weekly downloads. The Package JSON Generator creates package.json files. The Git Commit Generator follows Conventional Commits spec that drives semantic version bumps with tools like semantic-release. The JSON Formatter reads package.json and package-lock.json files. All are in the Dev Tools section.