Overview
Introduction
A commit message can look right at a glance and still fail commitlint in CI: a missing space after the colon, an unrecognized type, a body glued directly to the header with no blank line separating them.
This tool checks a pasted commit message against the Conventional Commits spec and lists every specific issue found, so you can see exactly what to fix before committing or opening a PR.
What Is Conventional Commit Message Validator?
A Conventional Commits linter that runs entirely in your browser. Paste a full commit message, header plus optional body and footer, and it reports whether the message is valid, along with a line-by-line list of errors and warnings.
It checks the same shape this site's Commit Message Generator produces, so a message that validates cleanly here is one the generator could have built.
How Conventional Commit Message Validator Works
The first line is parsed against the `type(scope)!: description` pattern to extract the type, optional scope, breaking-change marker, and description, then each piece is checked: the type against the allowed list, the description for emptiness, casing, and trailing punctuation, and the header overall for length and correct colon spacing.
The remaining lines are checked for a blank line separating them from the header, and scanned for a `BREAKING CHANGE:` footer, which is then cross-checked against whether the header itself carries a breaking-change `!` marker.
When To Use Conventional Commit Message Validator
Use it before committing, to catch a malformed type or missing colon-space before commitlint (or a CI check built on it) rejects the commit.
It's also useful for reviewing someone else's proposed commit message, or for teaching Conventional Commits by showing exactly which rule a sample message breaks.
Often used alongside Conventional Commit Message Generator, Commitlint Config Generator and Git Hooks Generator.
Features
Advantages
- Reports every issue found in one pass, not just the first failure, so all the fixes needed are visible at once.
- Distinguishes hard spec violations (errors) from style conventions (warnings), matching how tools like commitlint separate rule severities.
- Runs entirely client-side; the pasted message never leaves the browser.
Limitations
- Checks structure and the allowed type list, not whether the description accurately reflects the actual code change, that judgment call is still up to the author or reviewer.
- Only recognizes the `BREAKING CHANGE:` footer token, not arbitrary custom footer tokens a team's commitlint config might also enforce (like a required `Refs:` trailer).
Examples
Best Practices & Notes
Best Practices
- Fix every error before committing; a message with an error won't be reliably parsed by changelog or semantic-release tooling.
- Treat warnings as worth fixing too, since they're the same conventions tools like commitlint enable by default in most team configs.
- Pair this with the Commit Message Generator so messages are built correctly from the start, and use this validator to spot-check messages written by hand or pasted from elsewhere.
Developer Notes
The header is parsed with a single regular expression capturing the type, an optional `(scope)` group (matched even when empty so an empty-scope mistake gets a specific message instead of a generic parse failure), the breaking-change `!`, the single space required after the colon, and the description. Body/footer checks operate on the raw lines after the header: a non-blank second line is a spec violation, and a `BREAKING CHANGE:` footer is detected with a multiline regex and cross-referenced against the header's own `!` marker. The allowed type list intentionally matches the Commit Message Generator's `ConventionalCommitType` union exactly, rather than the larger community type lists (build, ci, style, etc.) some teams layer on top.
Conventional Commit Message Validator Use Cases
- Validating a commit message before running `git commit`, especially one written by hand rather than through the generator
- Reviewing a contributor's proposed commit message in a PR against the project's Conventional Commits convention
- Debugging why commitlint or a CI Conventional Commits check rejected a specific commit
Common Mistakes
- Forgetting the space after the colon (`feat:add x` instead of `feat: add x`), which is easy to miss visually but breaks strict parsers.
- Writing a `BREAKING CHANGE:` footer with no description, or marking the header breaking with `!` but never adding the footer that explains what changed.
- Gluing the body directly to the header with no blank line, which most Conventional Commits tooling (including this validator) treats as a spec violation.
Tips
- Run a message through this validator, then through the Commitlint Config Generator's rules, if your team enforces stricter or additional footer tokens beyond the base spec.
- When the validator flags an unknown type, check whether the message actually needs `build`, `ci`, or `style`, community extensions this validator doesn't accept, and adjust to one of the seven base types or update your team's convention accordingly.