Conventional Commit Validator

How to use

1. 1Paste a commit message or the output of `git log` or `git log --oneline` into the input area. A bullet list or a single subject line also works.
2. 2Read the per-commit cards. Each card shows the parsed type, scope, breaking marker, description, body, footers, breaking change reason, issue references, and the suggested version bump.
3. 3Review the issues list under each card. Errors are spec violations, warnings are style problems, and info notes call out useful context.
4. 4Tick `Warn on non-Angular types` to enforce the feat / fix / perf / refactor / docs / style / test / build / ci / chore / revert list, or untick it to allow any lowercase type.
5. 5Tick `Skip merge commits` to ignore `Merge branch ...` and `Merge pull request ...` entries the way semantic-release does.
6. 6Check the Summary card for the roll-up bump (major, minor, patch, or none) across all commits, then use Copy full report to drop the audit into a pull request, review comment, or repo policy doc.

About this tool

Conventional Commit Validator parses one commit message or a whole batch of commits and validates each one against the Conventional Commits 1.0.0 specification used by commitlint, semantic-release, release-please, and most modern release tooling. Paste a single subject line, a complete message with a body and footers, a `git log --oneline` paste, a full `git log` paste (with commit / Author / Date headers), or a bullet list, and the input splitter detects the shape automatically, strips the `commit <sha>` and Author / Date header lines, dedents the four-space message indent, and produces a list of structured commits. For every commit the tool shows the parsed type, the optional scope, whether the breaking-change ! marker is set, the description, the body, and the trailer footers (Refs, Fixes, Closes, Reviewed-by, Signed-off-by, Co-authored-by, BREAKING CHANGE, and any custom token). Issue references like #1182 and GH-1182 are extracted from the header, body, and footers and shown as pills. A live issues panel surfaces every spec violation and stylistic warning: empty type or description, missing colon-space after the prefix, missing blank line between header and body, missing blank line between body and footers, uppercase types, empty `()` scope, trailing period on the subject, past-tense openers like `added` or `fixing` instead of the imperative mood, header lines over 50 or 72 characters, non-Angular types when strict-type linting is on, trailers that do not match a `Token: value` or `Token #issue` shape, and breaking-change markers without a BREAKING CHANGE footer. Each commit is tagged with the semantic-release bump it would trigger (major for any breaking change, minor for feat, patch for fix or perf, none for everything else) and a roll-up across the entire input answers the question 'given this set of commits, what version bump applies?'. Two settings let you skip merge commits (which most tools ignore) and toggle strict Angular-type warnings. A Copy full report button emits a plain-text audit you can paste into a pull request, a code review comment, or a repo policy doc. Useful for engineers learning Conventional Commits, repo policy authors writing or auditing commitlint rules, release managers previewing the next semantic-release version from a draft changelog, contributors checking a commit message before pushing, and teams adopting release-please who want to lint a backlog of recent commits before turning the bot on. Everything runs locally in your browser, so private repository commit messages, issue numbers, and footers never leave your device.

Free to use. Works in your browser. No signup, no login.