Conventional Commit Message Formatter
Build a spec-compliant Conventional Commits message from a type, scope, and description, or paste an existing commit message to parse it back into its parts. Tracks the 72-character subject limit and adds a BREAKING CHANGE footer automatically.
Input
Optional area of the codebase this change affects.
Short summary in the imperative mood, no trailing period.
Output
| Check | Result |
|---|---|
| No data yet | |
More ways to use this tool
REST API
curl -X POST https://api.iotools.cloud/v1/tool/conventional-commit-message-formatter \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"mode": "build",
"type": "feat",
"scope": "auth",
"description": "add OAuth2 login support",
"breaking": "true",
"breakingDescription": "The login() function now requires an options obj…",
"body": "Implements the OAuth2 authorization code flow us…",
"footers": "Refs: #482"
}'Swap in your own key from your account. The tool's fields are the body — no wrapper.
Ask an AI agent
Use the IOTools `conventional-commit-message-formatter` tool (Conventional Commit Message Formatter) on this input:
YOUR_INPUT_HEREPaste this at any agent connected to the IOTools MCP server, then add your input.
Embed widget
<iframe
src="https://iotools.cloud/embed/conventional-commit-message-formatter/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="Conventional Commit Message Formatter — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>Drop this into your own page — free, no key required, just a link back.
| Cost per API/MCP call | From 5 credits |
|---|---|
| Need more credits? | View pricing |
Also available with
Guides
Conventional Commits is a strict,
machine-readable format for commit messages: a type, an optional scope, a
short description, and optional body/footer sections. Tools like
commitlint, semantic-release, and automated changelog generators all parse
that exact shape — one stray character (a missing colon, an extra space, the
wrong footer syntax) and the commit silently fails validation or gets skipped
from the changelog. This tool builds a spec-compliant message from a form so
the format is always right, and can also parse an existing message back into
its parts. Everything runs in your browser.
How to use it
- Pick Build message.
- Choose a Type (
feat,fix,docs, …), and optionally a Scope (the area of the codebase affected, e.g.apiorparser). - Write a short Description in the imperative mood ("add", not "added").
- Check Breaking change if the commit breaks backward compatibility, and
describe the break — it's added as a
BREAKING CHANGE:footer and an!after the type/scope, exactly as the spec requires. - Add an optional Body for a longer explanation, and Footers for
things like
Refs: #123orReviewed-by: Name(one per line). - Copy the formatted message straight into
git commit -m "..."or your editor's commit message box.
Switch to Parse message to do the reverse: paste an existing commit message and the tool breaks it back down into type, scope, breaking-change flag, description, body, and footers — useful for checking whether a message someone else wrote actually follows the spec.
Subject line length
The Subject Check table tracks your formatted header (type(scope)!: description) against the commonly-used 72-character limit, so long subject
lines that would get truncated in git log --oneline or GitHub's commit list
are caught before you commit.
Commit types
feat and fix map directly to semantic-version bumps under
Semantic Versioning when a tool like semantic-release
reads your history, and a BREAKING CHANGE footer (or !) triggers a major
bump regardless of type. The rest — docs, style, refactor, perf,
test, chore, ci, build, revert — describe the change without
affecting the version number.
Does this replace a commit hook like commitlint?
No — commitlint validates commits at commit time (usually via a Git hook) and is meant to run automatically in a team's workflow. This tool is for writing one message by hand, or for checking a message before you paste it in. Use both: this to compose the message, commitlint to enforce the rule automatically.
What if I need to review a whole commit history instead of one message?
Use the Git Log Formatter / Prettifier
to turn git log output into a table, list, or JSON — or the
Git Cheatsheet for common Git commands.