Free tool

Conventional Commit Builder

Fill in a guided form and live-build a spec-compliant Conventional Commit - with inline hints and a one-click copy. Nothing leaves your browser.

Compose

Type

Correlates with a MINOR version bump.

Scope (optional)

A noun describing the affected area of the codebase.

Description

Short imperative summary. Lowercase, no trailing period.

Body (optional)

Footer (optional)

Metadata as Token: value pairs, one per line.

Breaking change (adds ! and a footer)

Commit

feat: <description>

Spec hints

✕A description is required after the type/scope prefix.

Structured commits your tooling can read

A Conventional Commit encodes intent in the first line: type(scope)!: description. That small amount of structure lets release tooling decide how to bump a version, group a changelog, and route review - no hand-curated notes required. The type maps to a version bump (fix to PATCH, feat to MINOR, a breaking change to MAJOR), and the optional scope names the affected area.

Two habits do most of the work: keep the header at or under 50 characters so it survives every log and PR list, and write the description in the imperative mood - "add", "fix", "remove" - so it reads as "this commit will…". The body and footers carry the rest: the why, references, and any BREAKING CHANGE: note. This builder assembles all of it and flags the common mistakes as you type.

Clean commit history is also the raw signal behind engineering measurement. If you want history that feeds DORA metrics, cycle-time analytics, and a clean changelog, read our conventional commits guide or try the commit message generator.

Frequently asked questions

It is a convention that structures commit messages as type(scope)!: description, optionally followed by a body and one or more footers. The prefix makes history machine-readable, so tools can generate changelogs and pick semantic version bumps automatically.

Both signal a breaking API change. You can add a ! after the type or scope, include a BREAKING CHANGE: footer, or do both. This builder adds both when you toggle Breaking change, so the intent is unambiguous. A breaking change triggers a MAJOR version bump.

The body explains the what and the why over one or more paragraphs, wrapped at about 72 characters. Footers hold metadata as Token: value pairs - for example Refs: #123, Reviewed-by: Jane, or a BREAKING CHANGE: note.

No. The builder is fully client-side - nothing is uploaded, logged, or stored. Copy the result and paste it into git commit or your editor.

Measure what you ship

Structured commits are step one. FeatureFactory helps engineering teams plan, build, and measure AI web development - with outcomes you actually own.

Get early access