Skip to content
100% local

Conventional commit builder

Compose a Conventional Commits message from a type, scope and description, or check existing messages for problems.

Input
Output

Conventional commit builder

Conventional Commits is the "type(scope): description" format that changelog generators, semantic-release and commitlint all expect. This tool composes one for you: pick a type, add an optional scope, write the description, and it assembles the header — plus a body and a footer with ticket references, if you add them. Switch to check mode to do the opposite: paste one or more existing commit messages, one per line, and see exactly what's wrong with each.

The type list covers the standard set — feat, fix, docs, style, refactor, perf, test, build, ci, chore and revert. A breaking change toggle marks the header with "!" and, once you add a note, appends a "BREAKING CHANGE:" footer line, exactly as the spec expects. The max header length option enforces the length budget your team has agreed on (commitlint's own default is 72 characters); forcing a lowercase start and forbidding a trailing period are the two style rules most commit linters check by default, and both can be turned off if your team doesn't use them.

In check mode, each line is treated as one full commit header, so pasting the output of "git log --oneline" checks a whole batch at once. Choose whether the output is a report — the original line followed by what needs fixing — or the corrected message, auto-lowercased and de-punctuated wherever that's unambiguous. A line that doesn't follow the type(scope): description shape at all is left untouched rather than guessed at.

Everything runs in your browser, so commit messages from a private repository never leave your device. Copy the result, download it as a .txt file, or send it back into the input to refine it further.

FAQ

What is a Conventional Commit?
A commit message written as "type(scope): description", optionally followed by a body and a footer. Tools like commitlint, semantic-release and changelog generators parse this format to decide version bumps and group release notes.
How does check mode work?
Paste one commit message per line — a header only, like a line from "git log --oneline". Each line is validated against the type list, the header length limit and your lowercase/period rules, and reported separately.
How do I mark a breaking change?
Turn on "Breaking change" and add a note. The header gets a "!" before the colon and, once the note is non-empty, a "BREAKING CHANGE: …" footer line is appended, matching the Conventional Commits spec.
Can I add ticket references to the footer?
Yes — type them into the footer field, e.g. "Closes #123, refs JIRA-456". It is appended as its own line after the body.
Is my commit history uploaded anywhere?
No. Building and checking commit messages runs entirely in your browser — nothing you type or paste is sent to a server.