Semantic Versioning Helper
A SemVer 2.0.0 workbench: parse a version, see exactly what every release bump produces, test version ranges (^ ~ x hyphen ||) against a candidate, and turn a set of changes into the right bump plus a Keep-a-Changelog entry.
About this ToolHow it works, benefits & use casesTap to collapse
A complete Semantic Versioning workbench, not just a bump calculator. Type any version and it parses the full SemVer 2.0.0 string -- major, minor, patch, prerelease identifiers, and build metadata -- and flags it valid or invalid instantly. A "what each bump produces" table then shows the exact result of every release type (major, minor, patch, premajor, preminor, prepatch, and prerelease) so you can see, for example, that a prerelease bump turns 1.2.3 into 1.2.4-beta.0 and that 1.2.3-beta.0 becomes 1.2.3-beta.1. The headline feature is the range tester: enter a range using carets, tildes, x/star wildcards, comparators, hyphen ranges, or || unions, and a candidate version, and the tool tells you whether it satisfies the range plus a plain-English expansion of the bounds (^1.2.3 := >=1.2.3 <2.0.0). Finally, tick which kinds of changes are in your release and it recommends the correct bump with a rationale and hands you a Keep-a-Changelog style CHANGELOG.md block for the resulting version. Everything is captured in a shareable URL.
How to Use
- 1Type your current version (with or without a leading v); the parsed breakdown and validity update live.
- 2Pick a prerelease identifier (alpha, beta, rc, next, canary) to control how prerelease bumps are tagged.
- 3Read the "what each bump produces" table and the before-after cards to see exactly what major/minor/patch/pre* yield.
- 4Use the range tester: enter a range (e.g. ^1.2.3 or 1.0.0 - 2.0.0 or ^1 || ^2) and a candidate version to check whether it satisfies, with the bounds explained.
- 5Tick the breaking / features / fixes checkboxes to get the recommended bump and a ready-to-paste CHANGELOG.md entry.
Key Benefits
- Full SemVer 2.0.0 parser including prerelease and build-metadata identifier arrays
- A next-versions table covering all seven npm-style release types, not just three
- Range tester supporting ^, ~, x/* wildcards, comparators, hyphen ranges, and || unions
- Plain-English range expansion so you know the precise bounds a dependency will accept
- Spec-correct precedence handling (prerelease < release; numeric vs alphanumeric identifiers)
- Change-to-bump recommendation with a rationale, plus a Keep-a-Changelog CHANGELOG.md block
- Shareable URL and a pipe-to menu to send output into related tools
Common Use Cases
- Deciding whether a set of changes is a major, minor, or patch release
- Predicting what npm version a dependency range like ^1.2.3 will actually install
- Working out the next prerelease tag for an alpha, beta, or release-candidate build
- Checking whether a candidate version falls inside a complex range with unions and wildcards
- Generating a clean changelog entry for a release without hand-formatting markdown
Parsed version
valid SemVer1
major
4
minor
2
patch
What each bump produces
| major Incompatible API changes | 2.0.0 |
| minor Backwards-compatible features | 1.5.0 |
| patch Backwards-compatible bug fixes | 1.4.3 |
| premajor Next major, as a prerelease | 2.0.0-beta.0 |
| preminor Next minor, as a prerelease | 1.5.0-beta.0 |
| prepatch Next patch, as a prerelease | 1.4.3-beta.0 |
| prerelease Increment / start a prerelease | 1.4.3-beta.0 |
Prerelease rows use the beta identifier.
Current version
Try a bump
major
minor
patch
premajor
preminor
prepatch
prerelease
Range tester
Supports ^ ~ x/* wildcards, comparators (>= > <= < =), 1.0.0 - 2.0.0 hyphen ranges, and || unions.
1.5.0 satisfies ^1.2.3
^1.2.3 := >=1.2.3 <2.0.0
What changed?
Tick what is in this release and we will recommend the correct bump.
New backwards-compatible features call for a MINOR bump.
diff: minor
Keep-a-Changelog style block for the recommended version
## [1.5.0] - 2026-09-07 ### Added - Describe the new feature here.
MAJOR.MINOR.PATCH
Semantic Versioning gives a release number meaning. Bump MAJOR when you make incompatible API changes, MINOR when you add backwards-compatible functionality, and PATCH for backwards-compatible bug fixes. Prerelease tags like -beta.1 mark unstable builds that always rank below the matching stable release.
Why ranges matter
Package managers install whatever version satisfies a range. A caret ^1.2.3 allows any 1.x.x at or above 1.2.3 but never 2.0.0, while a tilde ~1.2.3 stays inside 1.2.x. The range tester above shows the exact bounds so you know precisely which updates a dependency will accept.
Was this tool helpful?
Share Your Experience
Help others discover this tool!
Related tools
- Changelog GeneratorGenerate changelog from Git commit history
- Commit Message GeneratorGenerate conventional commit messages
- npm to Yarn ConverterConvert npm commands and package-lock.json to Yarn equivalents
- Node Version Manager HelperGenerate .nvmrc, package.json engines field, and Node.js version files
- Package.json Scripts GeneratorGenerate common npm scripts for different project types and workflows
- Badge GeneratorBuild shields.io README badges with live preview, assemble a badge row, and export Markdown, HTML, reStructuredText or AsciiDoc
A caret range allows changes that do not modify the left-most non-zero version component. For ^1.2.3 that means anything from 1.2.3 up to but not including 2.0.0 -- so 1.9.9 is allowed but 2.0.0 is not. For 0.x versions the rule tightens: ^0.2.3 allows 0.2.3 up to but not including 0.3.0, because in 0.x a minor bump is treated as potentially breaking. The range tester shows you these exact bounds.
Tilde allows patch-level changes within a fixed minor version. ~1.2.3 permits 1.2.3 up to but not including 1.3.0, so 1.2.9 satisfies it but 1.3.0 does not. If you only specify a minor (~1.2) it still resolves to >=1.2.0 <1.3.0, and ~1 resolves to >=1.0.0 <2.0.0. Use tilde when you want bug fixes only; use caret when you also want backwards-compatible features.