Conventional Commit Builder
Compose a Conventional Commits message with the right type, scope, breaking change marker and footers, and validate an existing message against the specification.
Last reviewed by the Radiatus Cloud team
Build a message
Validate a message
Need this built for your product?
We design, build & host secure software & APIs.
A commit convention only pays off if it is consistent
Conventional Commits exist so that tooling can read history: semantic-release decides the next version number from commit types, changelog generators group entries by type, and a monorepo can work out which packages a change touched from the scope. All of that breaks the moment a commit says "fix: stuff" or forgets the exclamation mark on a breaking change, because the automation has no way to know it was wrong. The convention is only useful if every commit follows it.
The rules that get broken most
Four mistakes account for most invalid commits. The description starts with a capital or ends with a full stop, when the convention asks for lower case imperative mood with no trailing punctuation. The type is invented rather than taken from the agreed list. A breaking change is described in the body but never marked with an exclamation mark after the type or a BREAKING CHANGE footer, so the release tool ships it as a patch. And the header runs past the seventy two character soft limit, so it wraps badly in git log and on the platform UI.
What the builder and validator do
The builder assembles a correctly formatted message from the parts, shows the header length as you type, and adds the footers for breaking changes and issue references in the exact form the parsers expect. The validator reads an existing message and reports each rule it violates with the reason, including the version bump that semantic-release would derive from it, which is usually the fact people actually want to check.
Related tools
- JSON Formatter — Format and beautify JSON in your browser. Pinpoints syntax errors by line and column, flags unsafe integers, and never uploads your data to a server.
- JSON Validator — Validate JSON syntax with precise line and column errors, and check documents against a JSON Schema. Runs locally in your browser, nothing uploaded.
- Regex Tester — Test regular expressions against sample text with live match highlighting, capture groups and flag control. Runs entirely in your browser.
- HTML Minifier — Minify HTML by removing comments and redundant whitespace, without breaking inline elements or pre blocks. Runs entirely in your browser.
Frequently Asked Questions
Which version bump does each type produce?
With the default semantic-release rules, fix produces a patch, feat produces a minor, and any commit marked breaking produces a major regardless of type. Other types such as docs, chore and test produce no release at all unless your configuration says otherwise.
How do I mark a breaking change correctly?
Either put an exclamation mark after the type and optional scope, as in feat(api)!: drop v1 endpoints, or add a BREAKING CHANGE: footer describing it. The footer form is preferred when the explanation needs a sentence. Doing both is also valid.
Is the scope required?
No, it is optional. It is most valuable in a monorepo where it names the affected package or area, since tooling can then route the changelog entry. Keep the set of scopes small and agreed, or it stops carrying information.
Why does the description have to be lower case and imperative?
The imperative mood matches the git convention that a commit describes what applying it does, and consistent casing lets a changelog concatenate entries without post processing. The specification itself only requires that a description exists; the rest is the widely adopted commitlint default.
What is the character limit?
The specification sets none. The common commitlint default caps the header at 72 characters, which is what fits in git log without wrapping. The builder shows a live count against that limit.
Privacy & Security
Everything runs in your browser; nothing is uploaded.
How to Use
Pick a type, add a scope and description, then copy the formatted commit message. Paste an existing message to validate it.
Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.
Related Tools
JSON Formatter
DeveloperFormat and beautify JSON in your browser. Pinpoints syntax errors by line and column, flags unsafe integers, and never uploads your data to a server.
JSON Validator
DeveloperValidate JSON syntax with precise line and column errors, and check documents against a JSON Schema. Runs locally in your browser, nothing uploaded.
Regex Tester
DeveloperTest regular expressions against sample text with live match highlighting, capture groups and flag control. Runs entirely in your browser.