Commit message linter
Check commit messages against the Conventional Commits rules of commitlint's config-conventional, with the same rule names and messages.
Input
Result
The result will appear here.Conventional Commits — feat(api): add streaming, fix: handle empty responses — is the format semantic-release, release-please and changelog generators read to decide the next version and write release notes, and commitlint is the tool most projects use to enforce it. Paste one or more messages and this checker applies the rules of @commitlint/config-conventional: the allowed types, lower-case type, a subject that is not sentence-case and does not end in a full stop, a header of at most 100 characters, blank lines before the body and footer. Each problem is reported with commitlint's own wording and rule name, so what you fix here is what the commit hook would complain about.
How it works
- The rules are reimplemented from commitlint's source rather than by running commitlint, so the check happens in the page; the rule set, severities and messages match config-conventional.
- Separate several messages with a line containing only ---. Merge commits, reverts, fixup!/squash! commits and bare release versions are skipped, as commitlint skips them by default.
- A breaking change — ! after the type, or a BREAKING CHANGE: footer — is pointed out, since it means a major version bump for release tools.
- One check commitlint does not make: a lower-case breaking change: footer gets a warning, because the specification requires the token in capitals and parsers ignore any other spelling.
Where your data goes
Nowhere. This tool runs entirely in your browser: the text you paste is processed by the page and is never transmitted to a server or written to a log.
This tool is free and needs no account. Its results exist only in your open page and are not saved anywhere.
What it costs
This tool is free, with no sign-in and no points.
Common questions
- Which types are allowed?
- The eleven config-conventional accepts: build, chore, ci, docs, feat, fix, perf, refactor, revert, style and test. Anything else — Fix with a capital, feature, update — fails the type-enum rule. Projects can widen the list in their own commitlint config; this checker uses the default one.
- Why is "feat: Add login page" an error?
- config-conventional forbids sentence case, start case, pascal case and upper case in the subject, so it must not start with a capital letter unless the word is always written that way. Write feat: add login page. A proper name can be kept by quoting it or putting it in backticks, which the case check ignores.
- Are Chinese commit messages allowed?
- Yes. Letter case only exists in scripts such as Latin, Greek and Cyrillic, so a subject like 更新安装说明 passes the case rules. The type must still be one of the English keywords: docs(readme): 更新安装说明 is valid, 文档: 更新安装说明 is not.
- Why is the header limit 100 and not 72?
- 100 is config-conventional's default. Many teams prefer 72 so that headers fit git log --oneline and GitHub's commit list without being cut off; set the maximum header length to 72 to check against that instead.
The open-source behind it
This tool is a self-contained implementation. conventional-changelog/commitlint (MIT) does the same job as a library — if you need this behaviour inside your own program, start there rather than calling a web page.
conventional-changelog/commitlintAlso known as
- commit message linter
- conventional commits checker
- commitlint online
- validate commit message
- conventional commit format
- git commit message format