Conventional commit builder

Choose a type, add an optional scope and a short description, and copy a message in the Conventional Commits format. Breaking changes get the exclamation mark and a BREAKING CHANGE footer, and the form warns about common style slips.

The part of the code base, for example api or auth. No spaces, colons or brackets.
One per line, for example Closes #123 or Reviewed-by: Name.

The message follows the format.

Runs in your browser: nothing you enter is sent anywhere.

How to use it

  1. Pick the type that matches the change: feat for features, fix for bug fixes, and so on.
  2. Add a scope if it helps, then write the description in the imperative: “add”, not “added”.
  3. Turn on Breaking change and explain it if the change is not backward compatible.
  4. Add a body for the why, and footers such as Closes #123.
  5. Copy the message and use it with git commit (for example git commit -F - and paste).

Format

type(scope)!: description

body

BREAKING CHANGE: explanation
Closes #123

Example

Type feat, scope auth, description add refresh token rotation produces feat(auth): add refresh token rotation.

Tips

  • Keep one logical change per commit so the type is accurate.
  • Put the reason in the body; the diff already shows the what.

Frequently asked questions

What is the Conventional Commits format?

A convention for commit messages: type(scope): description, then an optional body and footers. The specification (version 1.0.0) lets tools generate changelogs and decide version bumps from the history.

How is a breaking change written?

Either with an exclamation mark before the colon, as in feat(api)!: remove v1, or with a BREAKING CHANGE: footer, or both. This builder writes the mark when the option is on and the footer when you give an explanation.

Which types does the specification require?

Only feat and fix are defined by the specification itself (they map to minor and patch versions in semantic versioning). The other types come from the Angular convention and are widely used but optional.

Why 72 characters?

It is a common rule of thumb for the first line so it displays well in git log and on code hosts. The specification sets no limit, and tools like commitlint use their own.

Does the message leave my browser?

No. It is built locally, and you copy it into your git commit command or editor.

More in Developer

All tools in this category: Developer ·Updated November 3, 2026

Privacy choices

Google Analytics shows us which tools are used and whether they work. It may set cookies. Your choice is kept in this browser.