Conventional Commit Messages Checker

Rule profile:

Pick the lint posture for this paste before reviewing the message ledger.

Message parsing:

Use header list for git log subjects, or full blocks when you need BREAKING CHANGE footers checked.

Commit messages:

Paste one commit header per line, or use --- separators for full messages with bodies and footers.

Review commit input

{{ error }}

Allowed types:

Keep this aligned with the type-enum rule in your repository when the profile enforces known types.

Header length limit:

Short headers scan better in git log and release notes.

chars

Scope case:

Validate optional scope values without requiring every message to have a scope.

Breaking marker policy:

Choose how strongly to enforce breaking-change markers after a header is parsed.

Subject full stop:

Use this for teams that keep commit subjects as terse release-note fragments.

Ignore generated git lines:

Leave this on for mixed git log pastes; turn it off when a commit-msg hook must reject every line.

{{ header }}	Copy
{{ emptyTableTitle(tab.key) }} {{ emptyTableNote(tab.key) }}
{{ cell.value }} {{ cell.value }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Release notes become much easier to trust when every commit message carries a small, predictable signal. A subject such as updates or final tweaks can be meaningful to the author, but it gives reviewers and release automation almost no clue about whether the change fixed a defect, added a feature, or broke compatibility.

Conventional Commits add that signal to the first line of the Git message. The header begins with a type, may include a scope in parentheses, may include a breaking-change marker, and then ends with a short subject after a colon and space. The convention is intentionally compact because it has to survive real commit history, pull request squashes, release-note grouping, and automated version checks.

Common Conventional Commit signals and release meaning
Signal	Typical meaning	Release cue
`fix`	A bug or regression was corrected without adding a new public capability.	Usually patch.
`feat`	A compatible user-facing feature or API addition was introduced.	Usually minor.
`perf`	Performance changed while the public feature set stayed the same.	Often patch.
`!` or `BREAKING CHANGE:`	Existing users may need to change code, configuration, data, or workflow.	Major review.
Maintenance types	Documentation, tests, refactors, build settings, style, CI, and chores.	Usually no bump unless project policy says otherwise.

Conventional Commit header parts leading to validation status and release impact.

The convention works best when the team agrees what each type means. A release script can infer that feat looks like a minor release and fix looks like a patch, but it cannot prove that the code actually changed in that way. A message gate catches format drift; it does not replace review of the diff, migration notes, or repository-specific versioning rules.

The most common mistake is treating the header as decoration instead of release evidence. A good header is short, lower-case when the repository enforces that style, and specific enough that another maintainer can understand the change months later. Breaking changes deserve extra care because the marker affects both version planning and reader expectations in the changelog.

How to Use This Tool:

Review the messages under the same policy your repository expects. The checker updates the ledger, findings, release labels, and chart data as the input or rule settings change.

Choose Rule profile. Commitlint recommended applies common lower-case and length checks, Strict release gate requires paired breaking markers, Spec structural only focuses on the base grammar, and Custom type list uses your own allowed types.
Set Message parsing. Use one header per line for copied Git log subjects. Use full blocks separated by --- when message bodies or breaking-change footers matter.
Paste commit text, load a TXT or LOG file, or use Load sample to see the expected row shape. Uploaded text files are kept to the browser-side size limit of 1 MiB.
Use Normalize when a paste contains trailing spaces or long blank runs. Normalizing does not invent types or subjects; it only cleans the pasted text before validation.
Open Advanced if the repository has a specific type list, a header length limit, a scope-case rule, a breaking-marker policy, a subject-period rule, or a generated-line policy.
Read Rule Findings before using Release Impact. Errors make the row invalid, while warnings mark items such as a long header, scope-case mismatch, or final period in the subject.
Use Message Ledger, Release Impact, Commit Type Mix, or JSON for the audit view that matches your release review.

Interpreting Results:

Pass means the active rules accepted the message. Warn means the message parsed but matched a review rule. Fail means an error remains, so the release impact is shown as Invalid until the message is corrected.

Release impact is derived from the parsed message shape. A valid breaking marker maps to Major, feat maps to Minor, and fix or perf maps to Patch. Other valid types map to None in this checker unless your release process has additional rules outside the page.

Conventional commit result cues and follow-up checks
Cue	Meaning	Follow-up check
`format fixes needed`	At least one row has an error-level finding.	Open `Rule Findings` and fix the listed rule before release automation reads the message.
`review warnings`	Messages parse, but one or more warning rules fired.	Decide whether the team treats warnings as blockers or cleanup notes.
`release-ready headers`	Every checked message passed under the active profile.	Compare the inferred impact with the actual diff and release policy.
`Ignored`	A merge, fixup, squash, or amend line was skipped by the generated-line setting.	Turn off generated-line ignoring if your commit-message hook must reject those lines.

Technical Details:

The header grammar is small enough to audit directly. A candidate header needs a type that begins with a letter, may include letters, digits, or hyphens, may carry a parenthesized scope, may add ! before the separator, and must use : before the subject. Full commit blocks use the first non-empty line as the header and keep later lines available for footer checks.

The base Conventional Commits specification and lint profiles answer different questions. The specification defines the structural signal and the meaning of breaking-change markers. Team lint rules add local policy, such as allowed types, lower-case type names, header length, scope case, subject punctuation, and whether one or two breaking markers are required.

Rule Core:

Conventional commit validation rule core
Rule area	Pass condition	Finding when it fails
Header shape	The first meaningful line matches `type(scope)!: subject`, with scope and bang optional.	`header-format` or `header-empty`.
Whitespace	The header has no leading or trailing spaces.	`header-trim`.
Type policy	Recommended, strict, and custom profiles require lower-case allowed types. Spec-only mode accepts any syntactically valid type.	`type-case` or `type-enum`.
Scope policy	Scope is optional. Lower-case, kebab-style, and any-case behavior depends on the active profile and advanced setting.	`scope-case` warning.
Subject text	The subject after the colon-space separator is present. Commitlint-style checks can warn on a final period.	`subject-empty` or `subject-full-stop`.
Header length	The header stays at or below the active limit when that limit is greater than zero. The default recommended limit is 72 characters.	`header-max-length` warning.
Breaking marker	A breaking change uses `!`, a valid uppercase breaking footer, or both depending on policy.	`breaking-footer` or `breaking-marker-pair`.
Generated Git lines	Merge, fixup, squash, and amend lines are skipped when generated-line ignoring is enabled.	The row is marked `Ignored`.

Release Impact Core:

Release impact labels from parsed conventional commits
Parsed condition	Impact label	How to read it
Valid message has `!` or a valid breaking footer	`Major`	Plan compatibility review and migration notes.
Valid type is `feat` without a breaking marker	`Minor`	Route to feature notes and compatible-release review.
Valid type is `fix` or `perf` without a breaking marker	`Patch`	Route to patch notes or maintenance-release review.
Valid type has no version-bump meaning here	`None`	No version bump is implied by this checker.
Any error-level finding remains	`Invalid`	Fix the message before release tooling consumes it.
Generated-line policy skips the row	`Ignored`	The row is excluded from checked pass, warn, and fail counts.

Parsing mode changes which text is available to the rule engine. Header-list parsing checks each non-empty line as one candidate header. Full-block parsing keeps body and footer text attached to the first non-empty header, with blocks separated by a line containing only dashes. Auto-detect switches to block parsing when those separators appear.

Breaking footers must use an uppercase BREAKING CHANGE: or BREAKING-CHANGE: token followed by detail. Lowercase breaking footer labels and empty breaking-footer descriptions produce errors. In the strict profile, a header bang without a valid footer fails, and a valid footer without a header bang also fails.

The type-mix chart counts parsed types, invalid rows, ignored rows, failing rows, and breaking rows. It helps spot unusual batches, such as a release branch dominated by invalid headers or maintenance commits, but the row-level repair still comes from the ledger and rule findings.

Privacy and Limits:

Commit text and selected files are checked in the browser for the validation described here. That matters when messages contain unreleased feature names, issue references, customer context, or branch hints.

The checker cannot confirm that the selected type matches the actual diff, that a migration note is complete, or that your release tool uses the same custom policy. Treat the result as a message-quality check and release-impact estimate, then compare it with the code change and final release process.

Worked Examples:

A copied log containing feat(api): add retry envelope, fix: handle null coupon, and docs(readme): document cache flags should produce passing rows under the recommended profile. The release-impact view should label them Minor, Patch, and None.

A full message block with perf(search)!: replace fuzzy index, a blank line, and BREAKING CHANGE: fuzzy search index now requires a rebuild step should read as Major. Under the strict profile, using only the bang or only the footer creates a breaking-marker-pair error.

chore(ci): bump runner image. parses under the recommended profile, but the final period creates a warning. The release impact remains None because warnings do not make the row invalid.

updated readme fails because it has no type, separator, or subject structure. Rewriting it as docs(readme): update cache notes gives the checker enough structure to parse the type, scope, and subject.

FAQ:

Why did a valid-looking message fail?

The selected profile may be stricter than the base Conventional Commits shape. Check Rule Findings for type case, allowed type list, header spacing, missing subject, malformed breaking footer, or strict breaking-marker pairing.

When should full message blocks be used?

Use full blocks when body or footer text matters, especially for breaking-change footers. Separate commits with a line containing only --- so each footer stays attached to the correct header.

Why can a warning still have release impact?

Warnings do not make the message invalid. A long feat header can still map to Minor, but the warning tells you to review or clean up the message before release.

Does this decide the final version number?

No. It maps each parsed message to major, minor, patch, none, invalid, or ignored based on message structure and the active rules. The final version still depends on repository policy, release tooling, and human review.

Glossary:

Type: The leading category in the header, such as feat, fix, docs, or chore.
Scope: An optional parenthesized area such as api, readme, or auth.
Subject: The short description after the colon-space separator.
Bang: The optional ! before the colon, used as a breaking-change marker.
Breaking footer: A footer beginning with BREAKING CHANGE: or BREAKING-CHANGE:, followed by migration or compatibility detail.
Release impact: The derived label that points a valid message toward major, minor, patch, or no version bump.

References:

Conventional Commits 1.0.0, Conventional Commits.
Rules Reference, Commitlint.
Semantic Versioning 2.0.0, Semantic Versioning.