Loading page
About this tool
Lint a commit message against the Conventional Commits spec — type, scope, subject, body and footers — with a suggested fixed message.
This linter checks a git commit message against the Conventional Commits v1.0.0 specification and the default rules of commitlint's config-conventional preset: header shape (type(scope)!: description), allowed types, subject case and punctuation, header length, the blank line before the body, body line length and BREAKING CHANGE footers. It reports each violation with the rule name and produces a suggested corrected message, so you can fix a commit before commitlint or CI rejects it.
Open Git Commit Message Linter on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
Implements the header grammar and blank-line rule straight from Conventional Commits v1.0.0.
Each finding cites the commitlint rule (type-enum, subject-full-stop, body-leading-blank) so fixes map to config.
Generates a corrected message — lowercased type, trimmed subject, stripped trailing period — ready to copy.
type(scope)!: description — a type such as feat or fix, an optional scope in parentheses, an optional ! for breaking changes, then a colon and a single space before the description. A longer body, if present, must start exactly one blank line after the description, per the Conventional Commits v1.0.0 spec.
The spec itself only mandates feat and fix, but the widely used config-conventional preset (based on the Angular convention) allows eleven: build, chore, ci, docs, feat, fix, perf, refactor, revert, style and test. feat correlates with a MINOR version bump in semantic versioning and fix with a PATCH.
commitlint's config-conventional preset errors above 100 characters (header-max-length). The older git convention popularised by Tim Pope suggests about 50 characters for the summary line with body lines wrapped at 72, which keeps messages readable in git log and email patches. This tool lets you lint against either limit.
Two spec-compliant ways: append ! after the type or scope (feat(api)!: remove v1 endpoints), or add a footer starting with BREAKING CHANGE: followed by a description. BREAKING-CHANGE with a hyphen is defined as synonymous. Either form signals a MAJOR version bump to semantic-release and similar tooling.