Build conventional commit messages with type, scope, description, body, and footer following standards.
A Conventional Commits message begins with a compact header whose punctuation carries meaning. This tool combines a selected type with an optional parenthesized scope, a description, and optional body and footer sections, inserting the separators and blank lines required by the convention. It helps when you know what changed but want the final message arranged correctly. The important limitation is that formatting is not classification: the generator cannot determine whether a change is truly a fix, a feature, or breaking merely from the wording entered.
A concrete input and expected output from the current implementation.
Input
type: fix scope: parser description: reject empty input
Expected output
fix(parser): reject empty input
`fix` becomes the type, `parser` is enclosed in parentheses as the scope, and the description follows the colon and space. With no body or footer supplied, the result contains only the header.
The generated first line follows `<type>[optional scope][optional !]: <description>`. A supplied scope is placed in parentheses directly after the type; an empty scope removes both the value and its parentheses. If a breaking-change marker is selected, it belongs immediately before the colon. The description remains on the header, so it should summarize the change rather than provide the full rationale.
When present, the body starts after a blank line below the header. Footer text follows after another blank line and uses the convention's token-and-value form, such as `Refs: #18`; `BREAKING CHANGE: ...` is the defined multiword token. The generator arranges these sections into one message. It does not invent migration notes, issue identifiers, or explanations that the user did not enter.
No. Under Conventional Commits, `feat` signals a new feature and `fix` signals a bug fix, but the boundary depends on the repository's release policy and the substance of the change. A wording improvement, refactor, test update, or build change is not automatically a feature. Choose the type deliberately; the generator only expresses that choice.
Not necessarily. Conventional Commits permits a breaking change to be indicated by `!` in the header or by a `BREAKING CHANGE:` footer. The footer is useful when the migration impact needs explanation. If both are entered, keep them consistent. Neither notation proves that the change is incompatible, and repository-specific checks may impose additional requirements.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Format, validate, and beautify JSON with syntax highlighting and error detection.
Encode text or files to Base64 and decode Base64 strings back to their original form.
Format and indent SQL queries for better readability across all major dialects.
Convert HTML markup into clean Markdown syntax with support for tables and lists.
Write Markdown and see the rendered HTML output in real time with live preview.
Visualize unified diffs and patch files with color-coded additions and deletions.