Conventional Commit Linter
Check a commit message against Conventional Commits: type, scope, breaking change marker, description style, header length, body wrapping and footers, with the version bump it implies.
Free · No sign-up · Your inputs stay in your browser
Input
Lint a commit message (Conventional Commits)
Output
Valid
| Type | feat (A new feature (minor)) |
|---|---|
| Scope | auth |
| Description | add login throttling per IP and email |
| Breaking | yes |
| Version bump | major |
| Footers | BREAKING CHANGE: LOGIN_ATTEMPTS env var renamed to AUTH_MAX_ATTEMPTS; Refs: #412 |
Conventional Commits 1.0.0: a type, an optional scope, ! for a breaking change, a colon and a description, then an optional body and footers. The payoff is automation: semantic-release and release-please pick the next version from the types (feat is minor, fix is patch, a breaking change is major) and write the changelog from the descriptions.
Runs in this browser. Nothing you paste is sent to a server.
About this tool
Method, assumptions, practical next steps, and limits.
Why the format pays off
Release tools such as semantic-release and release-please read the types: feat produces a minor release, fix a patch, and a breaking change marker a major, and the descriptions become the changelog. That only works if every commit follows the Conventional Commits 1.0.0 specification.
Enforcing it
commitlint with the conventional config checks messages in a commit-msg hook (through Husky or lefthook) and in CI on pull request titles, which matters when pull requests are squash-merged and the title becomes the commit.