All tools

Conventional Commit Message Linter

Code

Lint a git commit message against the Conventional Commits v1.0.0 spec: header format, blank-line separation, footer tokens, and BREAKING CHANGE casing

Paste a commit message and this tool checks it against the Conventional Commits v1.0.0 spec: the type(scope)!: description header format, the required blank line before a body or footer, footer token formatting, and the exact uppercase BREAKING CHANGE casing the spec requires. It parses out the type, scope, breaking flag, description, body, and footers so you can see exactly how a changelog generator or semantic-release tool would read the message, then reports each problem as an error (a structural spec violation) or a warning (a style convention like lower-case types that most teams follow but the spec itself doesn't require). It is a heuristic linter rather than a full grammar implementation, so a footer value that wraps across multiple lines is not supported.

gitcommitlintconventional-commitschangelogsemver

How to use Conventional Commit Message Linter

  • 1.Paste a full commit message: header line, then optionally a blank line, a body, another blank line, and footers.
  • 2.Read the parsed type, scope, breaking flag, and footer list to confirm the message was understood the way you intended.
  • 3.Fix any error-level findings first, since those are spec violations that would confuse a changelog generator; warnings are style suggestions.

Frequently asked questions

Does this check whether I used the right type for my change?
No. It cannot know whether a change is really a fix or a feat, so it only checks structure: is the type present, is it lower-case, is it one of the common recognized types. Picking the semantically correct type is still up to you.
Why does an unrecognized type only produce a warning, not an error?
The Conventional Commits spec explicitly allows custom types beyond feat and fix, so a type outside the common build/chore/ci/docs/feat/fix/perf/refactor/revert/style/test set is only flagged as a convention mismatch, not rejected.
How does it detect a breaking change?
Either a ! immediately before the colon in the header (e.g. feat(api)!:) or a footer whose token is exactly BREAKING CHANGE or BREAKING-CHANGE, uppercase, per the spec. A lower-case variant like 'breaking change:' is flagged as a casing error since it won't be recognized by real changelog tooling.
Does it support multi-line footer values?
No. Each footer is read as a single line; if a footer's value legitimately wraps onto the next line, this tool will misread the wrapped line as body text or a separate malformed footer.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/conventional-commit-linter \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"message":"feat(auth): add OAuth2 login support","types":[]}'

Get an API key from your dashboard · Full API docs →

Related tools

Commit Message Generator (AI)Paste a git diff and get a Conventional Commits-style commit message back: type, scope, subject, and body, powered by GPT-4o miniCodeDiff ViewerView and generate unified diffs with colored added/removed line highlightingTextGit Command BuilderBuild git commands from a form: commit, push, branch, and moreCode