Check a commit message against Conventional Commits and commitlint, with its version bump
Runs in your browser. Nothing you type is sent anywhere. Checked against sources on 16 Oct 2026.A conventional commit starts with a type, an optional scope and a description, such as "fix(api): handle empty response". Paste a message to check it against the 12 rules of commitlint's config-conventional, see its parts, and see the release it means: feat is minor, fix is patch, a breaking change is major.
Paste the commit message, or tap a type such as feat or fix to start one.
Read the result: each rule it breaks, in plain words, with the parts the message was read as.
Fix the message until it passes; the release line shows whether it means a major, minor or patch version.
For a whole pull request, switch to A list of headers and paste git log --format=%s output.
Conventional Commits is a small format for commit messages that tools can read: release tools pick the next version number from it, and changelog tools turn it into release notes. Many teams enforce it with commitlint in a commit-msg hook, and a rejected commit message is a common small frustration.
The format. A header, then an optional body and footers, each separated by a blank line:
| Part | Example | Rule |
|---|---|---|
| Type | feat, fix, docs |
One of 11, lower case |
| Scope | (api) |
Optional, in brackets |
| Breaking | ! before the colon |
Or a BREAKING CHANGE footer |
| Description | add login page |
Small first letter, no full stop |
| Header length | At most 100 characters | |
| Footer | Closes #123 |
After a blank line |
What it checks. The twelve rules of @commitlint/config-conventional: ten errors (type empty, type case, type list, description empty, description case, full stop, header length, header spaces, body and footer line length) and two warnings (a blank line before the body and before the footer). Each failure is explained in plain words with the fix.
The version bump. The specification maps commits to Semantic Versioning: fix means a patch release, feat a minor one, and any breaking change, marked with ! or a BREAKING CHANGE footer, a major one. Other types such as docs or chore do not change the version on their own.
A whole pull request. Switch to the list mode and paste the output of git log --format=%s main..HEAD, one header per line. Each header passes or fails, and the release they add up to is named.
The answers were checked against @commitlint/lint 19 with config-conventional on more than 100 messages. Everything runs in your browser; nothing you type is sent anywhere.
A commit message whose first line is a type, an optional scope in brackets, a colon, a space and a short description, such as fix(api): handle empty response. The format comes from the Conventional Commits 1.0.0 specification, and tools use it to pick the next version number and to write changelogs automatically.
Use feat for a change users can see as a new capability, fix for a bug fix, and chore for maintenance that changes neither, such as dependency bumps. Releases follow from them: feat makes a minor version, fix a patch, and chore no release on its own. docs, style, refactor, perf, test, build and ci are the other standard types.
Put an exclamation mark before the colon, as in feat(api)!: remove the v1 endpoints, or add a footer after a blank line that starts with BREAKING CHANGE: and says what breaks. Either one makes the release a major version, whatever the type. Both together are allowed and common.
Usually because the header does not match type: description exactly, so commitlint finds neither a type nor a description. Common causes are a missing space after the colon, a space before it, a capital or unknown type, or no type at all. Paste the message here to see which part was misread.
Not with config-conventional: its subject-case rule rejects descriptions in sentence case, start case, pascal case or upper case, so Add login fails and add login passes. Text in backticks or quotes is ignored for this rule, so a name like `Button` at the start is fine. Teams that want capitals change the rule in their own config.
No. By default commitlint skips merge commits, reverts written by git, fixup! and squash! commits, and headers that are only a version number such as 1.2.3 or chore(release): 1.2.3. This page skips the same messages and says so, so a check here gives the same answer as the hook.
Rates and rules change; check the source before you rely on a figure.
Still stuck? Ask about Conventional Commit Checker and anybody who knows can answer. No account needed.
Same job, other tools: Twitter Card Validator – Check twitter:card tags and the og: tags X falls back to · HTTP 404 Not Found – What a 404 means, when to send it, and when 410 or 403 is the better answer · HTTP 429 Too Many Requests – What a 429 rate-limit error means, how Retry-After works and how to stop hitting it.
On the related tools: Readability Checker – Flesch reading ease and grade level, with what to change.