Conventional Commit Linter

Paste a commit message and see whether it conforms to the Conventional Commits v1.0.0 spec. Type, scope, subject length and form, body, footers, and the BREAKING CHANGE marker — all checked live. Rules are configurable; the Reformat button rewrites the input into its canonical form. Pure client-side, no upload.

Commit message

—

Rules — checks the live input against

Require scope — every commit must carry one Require body — enforce the explanatory second paragraph Require footer — enforce at least one trailer Forbid trailing period in the subject Forbid capitalised subject (info-level convention) Max header length Max subject length

Verdict

Idle Type a commit message above.

Findings

—

No findings yet.

Parsed

Parsed structure appears here.

Presets — one-click samples for the most common shapes

How the rules work

Header must match <type>(<scope>)?!: <description>. The ! is optional and marks a breaking change.
Type must be one of feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. The check is case-insensitive but the convention is lowercase.
Scope is a noun in parentheses, e.g. feat(api):. Turn on Require scope to make it mandatory.
Subject is the short summary after the colon. Keep it ≤ 72 chars (the default cap), lower-case, no trailing period, imperative mood (add, not added).
Body explains the why. Wrap at ~100 chars. Separate from the header with a blank line. Turn on Require body to make it mandatory.
Footers follow the Git trailer convention (token: value or token #value). Use BREAKING CHANGE: … (or ! in the header) to flag breaking changes.
Reformat rewrites the input into the canonical form: lowercase type, BREAKING CHANGE footer first, then the rest in input order.
Everything runs locally. Nothing leaves the browser.