Conventional Commits Builder

How to use

1. 1Pick a preset (New feature, Bug fix, Breaking change, Chore, Docs, Revert) to see a real commit shape, or start from scratch.
2. 2Choose a type (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert, or custom for your team) and optionally a scope like auth, api, or deps.
3. 3Write the description in the imperative mood (add, fix, remove). Keep the full subject within 50 characters when possible and never over 72.
4. 4Add a body to explain the why and what changed. Turn on Wrap at 72 chars to keep the body readable in git log and review tools.
5. 5If the change breaks existing usage, tick Mark as breaking change and describe what consumers must update. The builder adds the ! marker and the BREAKING CHANGE: footer automatically.
6. 6Add footers for issue references (Fixes #123) and trailers (Reviewed-by, Co-authored-by, Signed-off-by). Use the token suggestions for the most common patterns.
7. 7Read the checks panel for release impact and style notes, then click Copy message or Copy git commit to paste into your terminal or pull request.

About this tool

Conventional Commits Builder turns a short form into a clean, spec-compliant commit message ready for git, GitHub, or your release pipeline. It implements the Conventional Commits 1.0.0 specification used by semantic-release, release-please, commitlint, commitizen, husky, and most modern release tooling. Pick a type (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert, or a custom type your team uses), optionally add a scope like auth, api, or deps, write the description in the imperative mood, and the header line is built and validated as you type. The 50-character recommendation and 72-character hard cap from the git community are surfaced as a live character counter and as warnings, so you can keep git log --oneline and pull request titles readable. Add a longer body to explain the why and the user-visible effect; the optional 72-character soft-wrap preserves blank lines, leaves URLs and long tokens on their own line, and inserts the blank line that separates body from header automatically. Mark a commit as a breaking change with a single checkbox: the builder adds the exclamation marker after the type or scope and emits the BREAKING CHANGE: footer at the bottom, which is what semantic-release and release-please look for when bumping the major version. Add as many trailer footers as you need with token suggestions for the patterns teams actually use (Refs, Fixes, Closes, Resolves, Reviewed-by, Signed-off-by, Co-authored-by, Reported-by). Values that start with a #issue number use the conventional space separator (Refs #1182), and everything else uses the colon trailer form (Token: value) so git interpret-trailers parses them cleanly. A checks panel calls out the release impact under semantic-release default rules (feat for minor, fix and perf for patch, anything breaking for major), flags past or progressive tense (added, fixed, fixing) and trailing periods that violate the conventional style, and warns when a long subject would be clearer with a body. A copy button hands you the full message; a second button wraps it as a git commit -m command for shells. Quick presets seed a new feature, a bug fix, a breaking change, a chore, a docs commit, and a revert so you can confirm the shape of each conventional commit type without rebuilding the form. Everything runs locally; the commit messages you draft here, including private repo content and issue numbers, never leave your browser.

Free to use. Works in your browser. No signup, no login.