Commit Message Formatter
Validate a Conventional Commits message, or build one from separate fields.
Paste a message to validate, or build one with the fields above.
How it works
Conventional Commits (v1.0.0) is what `semantic-release`, `standard-version` and most auto-generated changelogs actually parse — the type prefix decides whether a release is a major, minor or patch bump, so a malformed header is a broken release pipeline, not just an inconsistent commit log. This validates what you paste and builds a correctly-formatted message from separate fields.
Breaking changes have two spellings, both honoured
A ! right after the type or scope (feat!:, feat(api)!:) and a
BREAKING CHANGE: footer are both valid signals, and either one alone is enough — a release tool that
only checks one of the two silently under-bumps a version. Validation here reports a commit as breaking if either
is present.
Footers are found by scanning from the end, not the first blank line
A commit body is free text and may itself contain a line with a colon in it. Footers are identified by scanning backward from the last line: a contiguous run of `Token: value` or `Token #value` lines at the very end of the message, stopping at the first line that doesn't match that shape.
Example
fix(auth)!: require MFA for admin accounts validates as a breaking fix — the bang marks it, no footer
required — while a non-standard type like wip: is flagged as non-standard rather than rejected
outright, since it is still a real, parseable message.
Frequently asked questions
Why does it flag a non-standard type instead of rejecting it?
wip:, hotfix: and similar are real, parseable Conventional Commits headers — the spec's eleven types (feat, fix, build, chore, ci, docs, style, refactor, perf, test, revert) are a common convention, not a hard grammar rule. This flags a type outside that list as non-standard rather than treating the whole header as invalid.
Does a ! and a BREAKING CHANGE footer both count?
Yes, independently. A release tool reading this commit to decide a version bump only needs one of the two signals present, so a checker that only looks for one under-reports breaking changes that used the other spelling. This checks for either.
How does it separate the body from the footers?
By scanning backward from the last line: a contiguous run of Token: value or Token #value lines at the very end of the message is read as footers, stopping at the first line that doesn't match. A commit body is free text and may itself contain a colon, so scanning forward from the first blank line would misread it.
Related tools
Changelog Generator
Group Conventional Commits into a Keep a Changelog-style breakdown.
LocalSemVer Comparator
Compare two versions using SemVer 2.0.0 precedence, not string sort.
LocalGit Patch Parser
Parse git format-patch output into author, subject and diff.
LocalSemVer Range Checker
Check whether a version satisfies a range like ^1.2.0 or ~2.0.0.
LocalGit Diff Viewer
Render git diff output as a readable, colour-coded diff.
LocalCSV Linter
Check a CSV file for ragged rows and detect its delimiter, without converting it to anything.
Local