What is the Conventional Commits format?

It is a lightweight rule for the first line of a commit, written as type(scope): description. The type says what kind of change it is, the optional scope in parentheses names the affected area, and the description is a short imperative summary. A real example is feat(parser): add array literal support. Optional body and footer blocks follow after a blank line, and a footer such as Closes #42 links an issue. Tools read this structure to build a changelog and pick the next version.

What is the difference between feat and fix?

feat marks a new capability that did not exist before, like feat(auth): add passkey login. fix marks a correction to behavior that was already supposed to work, like fix(auth): reject expired tokens. The distinction matters because semver tooling reads feat as a MINOR bump (1.4.0 to 1.5.0) and fix as a PATCH bump (1.4.0 to 1.4.1). Use chore, docs, refactor, or test for changes that are neither a feature nor a user-visible fix.

How do I mark a breaking change?

Two parts. Put a ! right before the colon in the header, as in feat(api)!: drop v1 endpoints, and add a footer line that starts with BREAKING CHANGE: followed by what broke and how to migrate. Toggle the breaking switch in this tool and it writes both for you. A breaking change forces a MAJOR version bump (1.4.0 to 2.0.0) regardless of the type, so reserve it for changes that make callers update their code.

Why bother with this convention at all?

Structured commits let machines do work people used to do by hand. A tool like semantic-release reads your feat, fix, and BREAKING CHANGE markers, decides whether the next release is a patch, minor, or major, tags it, and writes the changelog grouped by type. Even without automation, a reviewer scanning git log sees fix(parser): handle empty input and knows the intent in one glance instead of decoding free-form messages.

What goes in the scope?

The scope is an optional noun in parentheses that names the part of the codebase the change touches, such as (api), (ui), (auth), or (deps). It is most useful in a monorepo or a large app where one type like fix could land in any module: fix(billing): round tax to cents is clearer than a bare fix. Keep scopes short and consistent, reuse the same set across the team, and leave the scope out when a change is truly project-wide.

What length should the description be?

Keep the whole header at or under about 72 characters so it reads in one line on GitHub, in git log --oneline, and in terminal blame. This tool warns once the description pushes the header past the recommended width. Write it lowercase, in the imperative mood (add, fix, remove, not added or fixes), and with no trailing period, since the header is a title and not a sentence. Put extra detail in the body instead.

Write a feature commit your changelog tooling understands

You just added passkey login and want semantic-release to bump the minor version and group it under Features. Pick feat, set the scope to auth, type add passkey login support, and copy the result: feat(auth): add passkey login support. The header lands clean, the tooling reads feat as a MINOR bump, and the line shows up in the next changelog exactly where reviewers expect it.

Mark a breaking API change so semver bumps to a new major

You are dropping the v1 REST endpoints. Pick feat, scope api, toggle the breaking switch, and write the migration note in the footer field. The tool produces feat(api)!: drop v1 endpoints followed by a blank line and BREAKING CHANGE: use the v2 routes; see the migration guide. Now your release pipeline cuts a MAJOR version automatically and warns downstream consumers.

Teach a team a consistent commit style

A new contributor is unsure how to phrase commits. Send them the tool link with the type dropdown right there: they pick fix, see the scope and description fields, and get an instant warning if they write a capitalized description or end it with a period. The whole team converges on the same format without anyone memorizing the spec.

Link the issue you are closing in the footer

A bug ticket is #214 and you want git and GitHub to close it on merge. Pick fix, write reject empty payloads, and put Closes #214 in the footer. The output is fix(api): reject empty payloads, a blank line, then Closes #214, so the issue auto-closes and the commit is traceable back to the report that prompted it.

Conventional Commit Generator

Build a spec-perfect commit line from a type, scope, and one-line summary, with live validation and footers

Runs locally
Category Developer & DevOps
Best for Formatting, validating, shrinking, or inspecting code-adjacent text.

Type

Scope (optional)

Breaking change(adds ! and a BREAKING CHANGE footer)

Description

Body (optional)

Footer (optional)

Commit message preview

# Pick a type and write a description to build your commit message

Description is required.

What this tool does

A free conventional commit generator that builds a commit message in the Conventional Commits format and checks it against the spec while you type. Pick a type (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert), add an optional scope like (api) or (auth), write a short lowercase description, and the tool assembles the header as type(scope): description. Mark a breaking change to add the ! marker and a BREAKING CHANGE footer automatically. Add an optional body for the why and a footer such as Closes #123 to link issues. The live preview shows the exact text you will paste into git commit, with a blank line between the header, body, and footer the way the parsers tooling like semantic-release and changelog generators expect. Validation flags a description that is too long, ends in a period, or starts uppercase, so your history stays clean and your automated changelog and semver bumps keep working. Everything runs in your browser; copy with one click. 100% client-side, nothing is uploaded.

Tool details

Input: Files + Text; The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output: Live result + Copy + Preview; The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy: Browser-side processing; The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share: Shareable URL state; Key settings are encoded in the URL so another person can reopen the same setup.
Performance budget: Initial JS <= 9 KB; No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit: Developer & DevOps · Developer; Category and role tags drive related tools, internal links, and quick fit checks.

How to use

1. Input

Paste or drop your content into the tool panel.
2. Process

Click the button. All processing is local in your browser.
3. Copy / Download

Copy the result or download to disk in one click.

How Conventional Commit Generator fits into your work

Use it in the small gaps between coding, reviewing, debugging, and shipping.

Developer jobs

Formatting, validating, shrinking, or inspecting code-adjacent text.
Preparing snippets for documentation, tickets, commits, or handoff.
Checking a small payload quickly without switching tools.

Developer checks

Run irreversible transforms like minify or obfuscate on a copy.
Keep secrets out of pasted snippets unless the tool explicitly stays local.
Use your normal tests or linter before shipping transformed code.

Good next steps

These links move the current task into a more complete workflow.

Real-world use cases

Write a feature commit your changelog tooling understands
You just added passkey login and want semantic-release to bump the minor version and group it under Features. Pick feat, set the scope to auth, type add passkey login support, and copy the result: feat(auth): add passkey login support. The header lands clean, the tooling reads feat as a MINOR bump, and the line shows up in the next changelog exactly where reviewers expect it.
Mark a breaking API change so semver bumps to a new major
You are dropping the v1 REST endpoints. Pick feat, scope api, toggle the breaking switch, and write the migration note in the footer field. The tool produces feat(api)!: drop v1 endpoints followed by a blank line and BREAKING CHANGE: use the v2 routes; see the migration guide. Now your release pipeline cuts a MAJOR version automatically and warns downstream consumers.
Teach a team a consistent commit style
A new contributor is unsure how to phrase commits. Send them the tool link with the type dropdown right there: they pick fix, see the scope and description fields, and get an instant warning if they write a capitalized description or end it with a period. The whole team converges on the same format without anyone memorizing the spec.
Link the issue you are closing in the footer
A bug ticket is #214 and you want git and GitHub to close it on merge. Pick fix, write reject empty payloads, and put Closes #214 in the footer. The output is fix(api): reject empty payloads, a blank line, then Closes #214, so the issue auto-closes and the commit is traceable back to the report that prompted it.

Common pitfalls

Capitalizing the description or ending it with a period. The header is a title, not a sentence, so write a lowercase summary with no trailing dot. The tool flags both the capital first letter and the period for you.
Forgetting the colon and the single space after the type. The spec is strict about the type(scope) prefix followed by a colon and exactly one space. Squashing the prefix against the text breaks every parser.
Marking a break only with the ! in the header and skipping the footer. The ! alone is a hint; release tooling reads the BREAKING CHANGE footer line to trigger a major bump. Use the breaking toggle so both get written.

Privacy

Every part of this tool runs as plain JavaScript inside your browser tab. The type, scope, description, body, and footer you type are assembled and validated locally; nothing is sent to a server and nothing is logged. One thing to know: the form fields round-trip through the page URL so a share link reopens the same draft, which means a link pasted into chat records your commit text in the recipient server access log. For a sensitive message, use the copy button and paste the text instead of sharing the URL.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Developer

Browse all tools for this role

Conventional Commit Generator

What this tool does

Tool details

How to use

1. Input

2. Process

3. Copy / Download

How Conventional Commit Generator fits into your work

Developer jobs

Developer checks

Good next steps

Real-world use cases

Write a feature commit your changelog tooling understands

Mark a breaking API change so semver bumps to a new major

Teach a team a consistent commit style

Link the issue you are closing in the footer

Common pitfalls

Privacy

FAQ

Semver Increment

.gitignore Generator

Semver Compare

JSON Formatter & Validator

AI Eval Planner

API Key Generator

ASCII Table Generator

ASCII Table Reference

awk + sed Cheatsheet

AWS CLI Cheatsheet

Backup Codes Generator

Barcode Generator