Conventional Commit Generator
Build a Conventional Commits message from a type, scope, description, body and footers, with live validation.
Header: 5 / 72 characters
Body, breaking change & footers
Commit message
Pick a type and write a description — your commit message appears here.How it works
This generator writes commit messages in the Conventional Commits v1.0.0
format: <type>[optional scope][!]: <description>, then an optional
body after a blank line, then optional footers. Pick a type, add a scope such as
api or parser, tick “Breaking change” to add the !
marker, and the header line is assembled live with a running character count against the
72-character limit most Git tooling and linters use.
The body is re-wrapped at 72 characters with a greedy word wrap that keeps your blank
lines, so paragraphs survive intact. Footers follow the spec’s token: value
and token #value forms: BREAKING CHANGE: for the breaking
description, Closes #12 for numeric issues, Closes: ABC-123 for
tracker keys, and Co-authored-by: trailers for anyone who paired with you.
The checks under the output flag what commitlint usually catches: a missing description, a
trailing period, a capitalised first word, past-tense wording instead of the imperative
mood, an over-long header, and body lines past 72 characters.
Copy the message, copy a ready-to-paste git commit command with each part as
its own -m argument (single-quoted and shell-escaped), or download it as a
.txt file to use with git commit -F. Everything runs in your
browser in plain JavaScript — no sign-up, no ads, and nothing you type leaves your device.
Frequently asked questions
What is a Conventional Commit message?
Conventional Commits v1.0.0 is a convention for commit messages. The first line is a type, an optional scope in parentheses, an optional exclamation mark for a breaking change, then a colon, a space and a short description, for example feat(api): add pagination. An optional body follows after a blank line, and optional footers such as BREAKING CHANGE or Closes #12 come last. Tools like commitlint, semantic-release and standard-version read that structure to enforce style and generate changelogs.
How do I write a breaking change commit?
There are two ways, and you can use both. Put an exclamation mark straight after the type or scope, as in feat(api)!: drop the v1 endpoints, and add a BREAKING CHANGE footer explaining what broke and what to do instead. Tick the Breaking change box here to add the marker, and fill in the BREAKING CHANGE footer field to add the footer. Either one tells release tooling to cut a MAJOR version.
Do commit types change the version number?
With semantic-release style tooling, yes. A fix commit produces a PATCH release, a feat commit produces a MINOR release, and any commit marked as breaking produces a MAJOR release. Types such as docs, chore, test and ci normally produce no release at all. Nothing you type here is sent anywhere: the message is built entirely in your browser, so it is safe to draft commits for private repositories.