CI/CD tools
Paste commits, enter your current version, and get a suggested release: next version, changelog draft, and build number.
Commits and version numbers are parsed in your browser. Nothing is uploaded, and no Git or CI service is ever called.
Paste commits or enter a version to begin.
Unrecognized lines never block the calculation; this only controls whether they show up in the changelog draft's "Other" section.
Paste commits or enter a version to begin.
Before you tag a release you usually answer three questions by hand: what the next version number is, what goes in the changelog, and what build number ships with it. This semantic release calculator answers all three from the same batch of commits, so the version, the changelog and the build string never drift apart.
It differs from typing a version bump yourself or copying entries into CHANGELOG.md: every suggestion comes from parsing each commit header with the same grammar as our Conventional Commit Builder, not from guessing at a diff or calling an AI service. Nothing you paste leaves your browser, and the tool never creates a tag, pushes, or calls any Git or CI API — it only produces text for you to use.
See what changes when the version, the changelog, and the build number all come from the same commits.
Some release calculators ask you to describe your changes in free text and send it to an AI to guess a version bump. This tool instead parses each commit header with the same conventional-commit grammar as our Conventional Commit Builder — the same input always produces the same suggestion, and nothing is ever sent over the network.
A standalone version calculator, a changelog generator and a build-number generator don't know about each other's output. Here the suggested version feeds directly into the changelog heading and into the {version} placeholder of your build number template, so all three stay in sync.
Once the release is drafted, the result panel links straight to our ENV diff tool so you can compare environment variables before deploying — a step every standalone changelog and build-number generator we compared leaves out.
What to know before you paste your first batch of commits.
Paste subjects the way `git log --pretty=format:%s` prints them — one `type(scope)!: subject` line per commit. Full multi-line messages with a body or a `BREAKING CHANGE:` footer aren't parsed here; mark breaking changes with `!` right after the type or scope instead.
Type your current version as strict semver (like 1.4.2) and, if needed, edit the build number template. The default `{version}+{yyyyMMdd}.{count}` uses the suggested version, today's date, and a build count you fill in yourself — the tool has no CI context to read a real build number from.
Turn off auto-generate to edit several fields before recomputing, then press Ctrl/Cmd+Enter to run once.
The badge (major, minor, patch or no change) shows which commit forced the bump — a breaking marker always wins over a plain feat or fix. Copy or download the changelog, copy the build number, or follow the ENV diff link before you tag the release.
Any input change grays out the previous result and disables copy/download until you regenerate it.
See what stays unparsedFour pieces that turn a batch of commit headers into a ready-to-use release draft.
This semantic release calculator reads `type(scope)!: subject` lines with the same grammar as our Conventional Commit Builder, ranks every recognized line's impact, and keeps the highest one — a single `!` or one `feat` anywhere in the batch is enough to raise the whole release.
Recognized commits are grouped into Breaking Changes, Features, Fixes and Other, rendered as Markdown you can copy, download as CHANGELOG.md, or paste straight into your release notes — breaking entries are always listed first.
Combine `{version}`, `{yyyy}`, `{yyyyMM}`, `{yyyyMMdd}` and a manually typed `{count}` into whatever build-number format your pipeline expects; unknown placeholders are left untouched and flagged instead of silently dropped.
A line that isn't a valid commit header is skipped for the version suggestion and counted separately instead of stopping the whole calculation — turn off "ignore" to still see it listed under Other in the changelog.
The edge cases worth knowing before you paste a real release's commits.
Answers to what people actually ask before trusting a commit-driven version suggestion.
Check that the line matches `type(scope)!: subject` exactly — a missing colon, a stray space, or unsupported syntax makes the whole line unrecognized, and unrecognized lines never contribute to the version suggestion. The recognized-line count under the result tells you how many lines were actually parsed.
This calculator always takes the highest impact across the whole batch. If most of your commits are `fix:` but even one is `feat:` (or carries `!`), the entire release bumps minor (or major), not patch — mixing a single feature commit into an otherwise patch-only release changes the outcome for all of them.
Edit the build number template in Options. The default `{version}+{yyyyMMdd}.{count}` inserts the version this semantic release calculator suggested, today's date, and a count you type yourself — there's no CI environment here to read a real build number from, so `{count}` stays manual.
A version number (semantic version, like 1.5.0) communicates compatibility to people and package managers; a build number (iOS's CFBundleVersion, Android's versionCode) is usually just an identifier CI systems use to tell builds apart, even across two builds that ship the same version. Neither is derived from the other automatically — bridging that gap by deriving both from the same commits is what this tool does.
The version above the changelog comes from your commits' impact (major, minor, patch or no change) applied to the current version you typed. The build number is a separate string rendered from the template in Options — it can include that same version via `{version}`, plus a date and a manually typed `{count}`, so two builds of the same version can still get different build numbers.
Didn't find your answer?
Paste your commits into this semantic release calculator, confirm the current version, and get a version suggestion, a changelog draft and a build number in seconds.
Everything runs locally in your browser — no sign-up, no upload, and no tag or deploy is ever triggered for you.
All parsing happens locally in your browser, and nothing is ever tagged or published for you.