Conventional Commit Message Builder
Build a Conventional Commits message with type, scope, breaking change, and footers, in your browser.
How to use
- Pick a commit type (feat, fix, …) and an optional scope.
- Write a short description, and add a body or footers if needed.
- Toggle breaking change when applicable, then copy the generated message.
About this tool
ShowHide
Fill in a type, an optional scope, a description, a body, and footers, and get a message that follows Conventional Commits 1.0.0 — assembled in the right order, with the blank lines the spec requires between the header, the body, and the footers. All eleven common types are offered, from feat and fix through docs, refactor, perf, test, build, ci, chore, and revert. Marking a breaking change does both halves of the convention at once: it adds the exclamation mark after the type or scope, which is what a reader sees at a glance, and it writes the BREAKING CHANGE footer, which is what release tooling reads to bump the major version. Everything runs locally in your browser — nothing is uploaded.
Frequently asked questions
What format does it follow?
The Conventional Commits 1.0.0 spec: type(scope)!: description, followed by an optional body and footers separated by blank lines.
How is a breaking change marked?
Enabling breaking change adds a ! after the type/scope and, if you provide a description, a BREAKING CHANGE: footer.
What goes in footers?
Metadata like issue references — for example Closes #123 or Reviewed-by: Name. Put one footer per line.
Is my input sent anywhere?
No. The message is assembled entirely in your browser; nothing is uploaded.
Does the type I pick affect the released version?
Only if your release tooling is wired to read it. The usual convention is that fix produces a patch release and feat a minor one, while a breaking change forces a major — but that mapping lives in semantic-release or changesets, not in the message itself.
Why write BREAKING CHANGE in the footer when the exclamation mark already says it?
They serve different readers. The mark is what a person sees scanning a log; the footer is what tooling parses, and it is the only place to explain what broke and what to do instead. The spec allows either, and using both is the clearest option.
Related tools
Semver Tools (Parser, Comparator, Bumper)
Parse, compare, and bump semantic versions side-by-side, with a range expander that shows what ^x.y.z and ~x.y.z actually cover.
Developer
HMAC Generator (SHA-1 / 256 / 384 / 512)
Compute HMAC signatures with Web Crypto — sign webhook payloads, verify API requests, hex or base64 output.
Developer
JSON to Protobuf Schema Converter (proto3)
Turn a JSON object into a proto3 .proto schema with typed fields and nested messages, in your browser.
Developer
.mailmap Tester
Paste a .mailmap and a list of author identities to see what each one resolves to, which entry did it, and which people finally merge into one.
Developer
Git Object ID (hash-object)
Work out the git object id of a blob, tree, commit or tag in both SHA-1 and SHA-256, with the header git hashes and the loose object path.
Developer
.gitignore Generator
Tick the languages, frameworks, editors, and operating systems you use — get one combined .gitignore ready to drop into a fresh repo.
Developer