Git & Version Control
Compose fields or validate one complete message. Custom types are welcome; Git is never executed.
Suggestions are common types. You can enter a custom type.
Start with Refs: #42 or Closes #42. Plain following lines continue the preceding value.
Messages stay in this browser. No repository or network request is used.
Conventional Commits 1.0.0 structure; no project rules or 50/72-character limit. Maximum 20,000 UTF-16 units.
Enter a description or a complete message.
A Conventional Commit Builder helps when you know what changed but want to review the exact text before committing. The form keeps the description, body and trailers separate; the validator accepts an existing message without overwriting the form. Both paths show the message and its declared release impact, so a misplaced breaking marker is visible before the text reaches your repository.
The Conventional Commit Builder inserts the header punctuation and blank lines between sections. An optional scope stays in parentheses, the description stays on the first line, and paragraphs keep their internal line breaks. Switch to validation to inspect an existing message while retaining your unfinished form.
A feature normally indicates a minor release. Adding ! before the colon or a valid breaking change footer changes the declaration to major, regardless of the type. The summary makes that difference explicit without pretending to inspect the code or choose your next version number.
The suggestions are common names, not a whitelist. Enter your own noun if the team uses another type. Check whether the change is a feature, a fix or an incompatibility; the checker cannot infer that from the description.
Body paragraphs need an empty line after the header. In the dedicated footer field, start with a token such as Refs: #42; a following plain line continues that value. Another token starts another trailer. The form supplies section gaps.
Automatic processing waits 350 ms. Turn it off to use the action button or Ctrl/Cmd + Enter. Editing a field, the raw message or the breaking option immediately disables export until the current input has been checked again.
Compose type, scope and a one-line description, then add optional paragraphs and trailers. FEAT and feat are treated alike for release intent, while the output preserves your spelling. Custom types and descriptions in other languages are accepted; subject length is counted but never capped at 50 or 72.
Paste one full message to check the header, required separator and recognizable trailers. Errors retain their source line and column, and the raw editor highlights the line. A line with a colon inside ordinary prose is not automatically invalid. The two modes keep separate drafts.
Use ! with or without a footer, or use BREAKING CHANGE: followed by an explanation. BREAKING-CHANGE is accepted as an equivalent token. Trailer values may continue on following lines; the next valid token ends the preceding value. Copy and download contain only the message.
The specification allows either case and asks implementors to treat types without case sensitivity. Choose a consistent team style. This checker preserves the type you wrote; FEAT still declares a feature. BREAKING CHANGE and BREAKING-CHANGE are the uppercase exceptions.
When practical, split unrelated changes into separate commits. One message has one type field here. Selecting feat for a mixed change does not prove that its fixes or compatibility effects are correctly described; review the body and breaking declaration yourself.
fix declares a patch, feat a minor change, and ! or a valid breaking footer a major change. The summary applies those priorities without calculating a version. Your release process may use additional rules, prerelease handling or repository history.
If the message is still a draft, correct the type and check it again. A typo such as feet can be structurally valid because custom types are allowed. Editing an existing commit is a separate repository operation; this page cannot perform an amend or rebase.
The specification leaves revert behavior to tooling authors. You may use revert and a Refs footer to describe the commits being undone. This checker accepts that structure but does not subtract earlier changes or infer the resulting release version.
Have a message structure we should check?
Return to the Conventional Commit Builder, review the declared impact and export the current message only after the input passes its structural checks.