Check every commit header of a pull request at once and see the release they add up to
Runs in your browser. Nothing you type is sent anywhere. Checked against sources on 16 Oct 2026.A pull request with twenty commits needs every header in the agreed format before it can be squashed or released. Run git log --format=%s main..HEAD, paste the output, and each header is marked as passing or failing with its first problem. The summary counts the passes and names the release they add up to: major if any is a breaking change, otherwise minor for a feature, patch for a fix.
Paste or type your input.
Choose the options you need.
Press Ctrl+Enter, then copy or download.
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.
| 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 |
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 rest of the article, and all 6 questions about Conventional Commit Checker, are on the Conventional Commit Checker page.
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.
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.
On the related tools: Readability Checker – Flesch reading ease and grade level, with what to change · JSONPath Evaluator – Evaluate a JSONPath expression and get the matching values and their paths.