Conventional Commit Builder — Free Online Tool

Compose or validate Conventional Commits 1.0.0 messages with scope, breaking changes and footers. Local commit-message linting in your browser.

Use this free online Conventional Commit Builder directly in your browser. No signup required, no data leaves your device. Part of Utilier — a collection of 139+ developer utilities.

What is Conventional Commit Builder & Validator?

Conventional Commits is a lightweight convention for commit messages that a machine can read: a type, an optional scope, a description, and optional body and footers. This tool builds a compliant message from fields and, going the other way, lints a pasted message against the 1.0.0 specification. It all runs in the page.

  • The header shape: The first line is type(scope): description, for example feat(api): add pagination. An exclamation mark before the colon, or a BREAKING CHANGE footer, signals an incompatible change.
  • Body and footers: After a blank line comes an optional body, then optional footers such as Refs: #123 or Reviewed-by: Ann. A BREAKING CHANGE: footer describes what breaks and how to migrate.
  • A lint, not a policy engine: The validator checks structure — a recognised header, a blank line before the body, sensible casing — and reports errors and softer warnings. It does not enforce a team's custom rules or commit-lint config.

Why use the Conventional Commit tool?

Structured commit messages are what let tools generate changelogs, pick the next SemVer bump, and group history by area. Getting the format right by hand is fiddly, especially breaking-change and footer syntax.

  • Feed automated releases: Release tooling reads the type to decide whether a change is a patch (fix), a minor (feat) or a major (breaking). A correctly formatted message is what makes that automation reliable.
  • Get the breaking-change syntax right: The relationship between the ! marker and the BREAKING CHANGE: footer trips people up. Building the message here produces both consistently.
  • Check before you commit: Paste a draft message and see whether it will pass a conventional-commit check, so a pre-commit hook or CI gate does not bounce it later.

When to use the Conventional Commit tool

Use it when writing or reviewing commit messages in a repo that follows the convention.

  • Composing a commit message with a scope, body and issue reference without misremembering the syntax.
  • Recording a breaking change with both the ! marker and an explanatory footer.
  • Validating a draft message before committing so a commit-lint hook does not reject it.
  • Reviewing a teammate's message for structural problems.
  • Learning the Conventional Commits format with a live, editable example.

How to use the Conventional Commit tool

Fill the builder, or paste into the validator.

  1. Pick a type: Choose feat, fix, docs and so on, and add an optional scope like api or ui.
  2. Write the description: Use a short, imperative, lower-case summary. The message assembles live below.
  3. Add detail: Optionally fill the body, a breaking-change description, and a footer token/value such as Refs / #123.
  4. Copy the message: Use the Copy button on the assembled commit message.
  5. Validate a message: Paste any commit message into the validator to see errors, warnings and the parsed structure.

Key features

  • Guided builder: Type, scope, description, body, breaking change and footers combine into a spec-compliant message.
  • Breaking-change handling: Produces the ! marker and a matching BREAKING CHANGE: footer together, the way the spec intends.
  • Structural validator: Checks the header pattern, the blank line before the body, casing and header length, and separates errors from warnings.
  • Parsed output: Shows the detected type, scope, breaking flag, body and footers so you can confirm it parsed as you meant.
  • Runs offline: No repo access and no network — pure text handling in your browser.

Common use cases

  • Automated changelogs: Ensure messages carry the type and breaking signals that changelog generators depend on.
  • Pre-commit confidence: Validate a message before a hook or CI check runs it.
  • Onboarding: Teach the convention with an interactive builder rather than a wiki page.

Examples

A scoped feature

type feat, scope api, description 'add cursor-based pagination'
feat(api): add cursor-based pagination

The scope goes in parentheses right after the type, and the description follows a colon and a single space.

A breaking change

type feat, breaking, description 'drop v1 endpoints', breaking desc 'v1 removed'
feat!: drop v1 endpoints BREAKING CHANGE: v1 removed

The ! flags the break in the header and the footer explains it — release tooling reads either to trigger a major bump.

A message that fails validation

added dark mode
invalid: header must match <type>(scope): <description>

There is no type or colon, so it is not a conventional commit; the validator explains exactly what is missing.

Common mistakes to avoid

Forgetting the space after the colon

Why it happens: The spec requires exactly 'type: description' with a space. 'feat:add x' without the space fails most conventional-commit parsers even though it looks fine at a glance.

How to avoid it: Build the message here, which always inserts the space, or run your draft through the validator, which flags the missing space specifically.

Using ! without explaining the break

Why it happens: The ! marker tells tooling a change is breaking, but readers still need to know what broke and how to migrate. A bare ! leaves that undocumented.

How to avoid it: Pair the ! with a BREAKING CHANGE: footer describing the impact — the builder here writes both when you tick the breaking option and fill the description.

Frequently asked questions

What is the format of a conventional commit?

The first line is a type, an optional scope in parentheses, an optional ! for breaking changes, a colon and a space, then 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 Refs: #123 come last.

Which commit types should I use?

The common set is feat, fix, docs, style, refactor, perf, test, build, ci, chore and revert. feat and fix are the ones that drive minor and patch releases in automated tooling. Custom types are permitted by the spec, but sticking to the common set keeps changelog tools predictable, so this tool treats unknown types as a warning.

How do I mark a breaking change?

Two ways, and you can use both. Put an ! immediately before the colon in the header (feat!: ...), and/or add a footer that starts with BREAKING CHANGE: followed by a description. Release tooling reads either signal to trigger a major version bump; the description in the footer tells humans what to change.

Does the validator enforce my team's commit-lint rules?

No. It checks the structure defined by the Conventional Commits 1.0.0 specification — a valid header, a blank line before the body, and reasonable casing and length — and reports the results as errors and warnings. It does not read a commitlint config or enforce project-specific scopes or types.

References

Privacy and availability

  • Runs entirely in your browser — zero server processing
  • No signup or account required
  • Works offline once loaded
  • Fast, lightweight, no external dependencies
  • Available as a browser extension for Chrome and Firefox