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
No rows for the current commit input.
{{ cell.value }} {{ cell.value }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Conventional commit messages give Git history a shape that people and release tools can read consistently. A header such as feat(api): add retry envelope carries the change type, an optional scope, and a short description in one line. That small structure helps changelog generation, release notes, and review queues because the intent is visible before anyone opens the diff.

The format matters most when commits feed automated release decisions. A feat header usually signals new functionality, a fix header usually signals a bug fix, and a breaking marker signals compatibility risk. Those labels are only useful when they are applied carefully. A perfectly shaped header can still use the wrong type, and an accurate change can still be missed by automation if the marker is malformed.

Conventional commit header parts flowing into rule checks, status labels, release impact, and fix guidance.

A single repository can use the same convention in several places: a local commit hook, a pull request title check, a release branch review, or a changelog pipeline. The goal is not to make every commit sound identical. The goal is to make the part that automation reads precise enough that reviewers can spend their time on the change itself.

Format checking has a clear limit. It can catch missing colons, a blank subject, a wrong type list, an unsafe breaking marker, or a subject that violates local style. It cannot prove that a commit deserves to be called a feature, that a migration note is complete, or that a release should actually ship.

Technical Details:

The Conventional Commits header is a compact grammar. A type starts the line, an optional scope sits in parentheses, an optional bang marks a breaking change, and the subject follows a colon and a space. Body and footer text can carry supporting detail, including a BREAKING CHANGE: footer that release tooling can treat as a major-impact signal.

Commitlint-style checks add project policy on top of the base grammar. A team may require lower-case types, restrict types to a known list, cap header length at 72 characters, warn about trailing periods, or set a scope case rule. Those choices are governance rules, not universal Conventional Commits requirements, so the same message can pass one profile and fail or warn under another.

Rule Core:

The checker evaluates each parsed message against the active profile and records every finding that changes trust in the header.

Conventional commit validation rules used by the checker
Rule Area	Pass Condition	Finding When It Fails
Header shape	Header matches `type(scope)!: description` with the scope and bang optional.	`header-format` error, or `header-empty` when no non-blank header exists.
Whitespace	The first meaningful line has no leading or trailing spaces.	`header-trim` error with a trim-spaces fix.
Type policy	Commitlint, strict, and custom profiles require lower-case types from the allowed list. Spec structural mode accepts any syntactically valid type.	`type-case` or `type-enum` error.
Scope policy	Scope is optional. When present, lower-case mode accepts lower-case scope text, strict mode expects kebab-style segments, and any-case mode skips this hygiene check.	`scope-case` warning, not a hard failure.
Subject text	The description after the colon is present, and the selected profile may reject a trailing period.	`subject-empty` error or `subject-full-stop` warning.
Header length	Header length is at or below the active limit when the limit is greater than zero.	`header-max-length` warning that names the actual character count and limit.
Breaking marker	A breaking change uses `!`, a valid uppercase `BREAKING CHANGE:` footer, or both, depending on the selected policy.	`breaking-footer` error for malformed footer text, or `breaking-marker-pair` error when paired mode expects both markers.
Generated Git lines	Merge, fixup, squash, and amend lines are skipped when generated-line ignoring is enabled.	The message is marked `Ignored` instead of being counted as pass, warn, or fail.

Release Impact Logic:

Release impact is derived after validation. A hard format failure becomes invalid, while warnings can still leave a message usable for release routing.

Release impact labels produced from parsed conventional commits
Parsed Condition	Impact Label	How to Read It
Header or footer marks a breaking change and no hard error blocks parsing.	`Major`	Prepare a migration note and major-version review.
Type is `feat` and no breaking marker is present.	`Minor`	Route to feature changelog and minor release notes.
Type is `fix` or `perf` and no breaking marker is present.	`Patch`	Route to patch release notes.
Type is valid but has no version-bump meaning in the checker.	`None`	No version bump is implied by the current type.
Any error-level finding remains.	`Invalid`	Fix the message before release tooling consumes it.
Generated-line policy skips the message.	`Ignored`	Excluded from the checked message count under the current setting.

Pasted headers, loaded text files under 1 MiB, full message blocks, result tables, charts, and JSON are all derived from the same normalized message set, so a finding in one result view should agree with the status and impact shown elsewhere.

Everyday Use & Decision Guide:

Start with Rule profile set to Commitlint recommended and Message parsing set to Auto-detect blocks. That first pass fits a pasted Git log, a commit hook payload, or a short release branch review without requiring you to decide upfront whether the input contains full bodies and footers.

Use One header per line when the source is a list of subjects from git log --oneline or a review spreadsheet. Use Full messages separated by --- when the body or footer matters, especially for breaking changes that are documented below the header. The separator must be on its own line so each commit remains a separate message block.

Choose Spec structural only when you want to check the basic Conventional Commits shape without enforcing a project type list.
Choose Strict release gate when release review should require kebab-style scopes and paired breaking markers.
Choose Custom type list when the repository uses types outside the default set or has a different header-length limit.
Leave Ignore generated git lines on for mixed history pastes; turn it off when a commit hook should judge every line.
Open Rule Findings before trusting the summary if the top box reports any fail or warn count.

A clean status does not mean the commit type is semantically correct. It means the message matches the active rules. For release work, compare Release Impact against the actual diff and any migration notes before tagging.

The tool is a poor fit for deciding whether a change is safe, rewriting a messy history for you, or replacing repository policy. It is a good fit for catching header mistakes before commitlint, semantic-release, changelog generation, or a human release reviewer sees the same messages.

Step-by-Step Guide:

Work from parsing choice to rule profile, then review findings before using the impact labels.

Paste commit text into Commit messages, or use Browse TXT for a TXT, LOG, or gitmessage file under 1 MiB. The source badge should update with line and character counts.
Set Message parsing. If Auto-detect blocks finds a line containing only ---, the input is treated as full message blocks; otherwise each non-empty line is checked as one header.
Choose Rule profile. Use the recommended profile for common commitlint checks, strict for release gating, spec structural for grammar only, or custom when Allowed types and Header length limit must match a repository rule.
Open Advanced when scope case, breaking marker policy, subject full stop, generated-line ignoring, or the type list needs adjustment.
Read the summary box. All pass, a warn count, or a fail count should match the rows in Message Ledger.
Open Rule Findings for every warning or error. Fix messages such as updated readme by adding a valid type, colon-space separator, and subject, for example docs(readme): update cache notes.
Use Release Impact to separate major, minor, patch, none, invalid, and ignored messages before release notes are prepared.
Check Commit Type Mix and JSON only after the ledger and findings look right, so the aggregate view is based on corrected messages.

Interpreting Results:

Read Fail first. A failed message receives Invalid impact, so it should not be used for changelog or version decisions until its error-level findings are fixed. Warn means the header parsed but failed a hygiene rule such as length, scope case, or trailing period.

Pass confirms the active rules accepted the message. It does not prove that the chosen type matches the code change, that a breaking-change footer is detailed enough, or that the repository's release automation uses the same impact mapping.

How to interpret conventional commit checker result cues
Result Cue	What It Means	What to Verify
`format fixes needed`	At least one checked message has an error-level finding.	Open `Rule Findings` and correct each listed rule before release review.
`review warnings`	Messages parsed, but at least one hygiene rule produced a warning.	Check whether your repository treats warnings as blockers.
`release-ready headers`	Checked messages passed under the active profile.	Compare `Release Impact` with the actual change set before tagging.
`Ignored`	A generated Git line was skipped by the current policy.	Turn off `Ignore generated git lines` if those lines must be rejected instead.

The Commit Type Mix chart is useful for spotting an unusual run, such as many invalid formats or a release made mostly of non-version-impacting types. Treat the chart as a summary, then return to Message Ledger for the exact rows.

Worked Examples:

A release branch paste with feat(api): add retry envelope, fix: handle null coupon, and docs(readme): document cache flags should show passing rows in Message Ledger. Release Impact separates the first as Minor, the second as Patch, and the documentation change as 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 be read as Major. Under Strict release gate, a similar message with only the bang or only the footer fails the paired marker rule until both markers are present.

A header such as chore(ci): bump runner image. parses, but the default subject full stop rule produces a warning. Rule Findings should name subject-full-stop, while Release Impact remains None because the warning does not make the type version-impacting.

A troubleshooting paste that contains updated readme should fail with header-format. Rewriting it as docs(readme): update cache notes gives the checker a type, scope, colon-space separator, and subject, so the row can move from Fail to Pass under the recommended profile.

FAQ:

Why did a valid-looking commit fail?

The active profile may be stricter than the base Conventional Commits shape. Open Rule Findings and check whether the issue is the type list, type case, header trim, empty subject, malformed breaking footer, or paired breaking marker rule.

When should I use full message blocks?

Use full message blocks when body or footer text matters. Separate commits with a line containing only --- so a BREAKING CHANGE: footer stays attached to the right header.

Why is a warning still assigned a release impact?

Warnings do not block parsing. A long feat header can still show Minor, but the warning should be reviewed before the message is used in a release process.

Does the checker decide the correct SemVer version?

No. It labels each message as major, minor, patch, none, invalid, or ignored from the parsed header and breaking marker. Your release tool, branch policy, and human review still decide the final version.

Does pasted commit text leave the browser?

Validation runs in the page for pasted text and loaded text files. The checked workflow does not send commit message content to a server.

Glossary:

Type: The leading commit category, such as feat, fix, or docs.
Scope: An optional parenthesized area after the type, such as (api) or (readme).
Subject: The short description after the colon and space in the header.
Breaking marker: A bang before the colon or a valid BREAKING CHANGE: footer that signals compatibility risk.
Release impact: The checker's major, minor, patch, none, invalid, or ignored label for a parsed message.
Generated Git line: A merge, fixup, squash, or amend line that can be skipped when the ignore setting is enabled.

References:

Conventional Commits 1.0.0, Conventional Commits.
Rules reference, commitlint.
Concept: Commit conventions, commitlint.
Semantic Versioning 2.0.0, Semantic Versioning.