What is the Conventional Commits format?

It is a lightweight convention of the form type(scope): subject, with an optional body and footer. Common types include feat, fix, docs, chore, refactor, test, and build. A type of feat or fix combined with a BREAKING CHANGE footer signals a semantic version change.

Why should the subject line be short?

Conventional Commits recommends a concise subject so it reads cleanly in git log, GitHub, and changelogs. The linter warns when the subject exceeds the common length guideline so it stays readable across tools.

Can it fix every message automatically?

It auto-corrects mechanical issues like casing, trailing punctuation, and spacing. It cannot invent a meaningful type or scope for you, so messages that lack semantic intent still need a human edit.

How do I mark a breaking change?

Add a BREAKING CHANGE: footer describing the incompatibility, or append a ! after the type or scope. The linter checks that breaking-change markers are well formed.

Is my commit text sent anywhere?

No. Linting and formatting happen entirely in your browser, so the message you paste is never uploaded or stored.

Git Commit Message Linter

Analyze your Git commit messages against Conventional Commits standards and get automatic fixes.

Commit Message

Paste your commit message below to validate it against Conventional Commits standards.

Your Commit Message

Quick Templates

Start with a template

Conventional Commits Guide

Learn about the Conventional Commits specification

What is Conventional Commits?

Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. It provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of.

Format Structure

type(scope): description

[optional body]

[optional footer(s)]

type: The kind of change (required)

scope: What section of codebase (optional)

description: Brief summary (required)

body: Detailed explanation (optional)

footer: Breaking changes, issue refs (optional)

Examples

Simple

feat: add user authentication

With Scope

fix(api): resolve timeout issue

Breaking Change

feat(auth)!: change login endpoint

BREAKING CHANGE: endpoint changed from /login to /auth/login

With Body & Footer

fix(database): prevent connection leak

Added proper connection pool cleanup.
Improved error handling for timeout cases.

Closes #456

Commit Types

✨featA new feature

🐛fixA bug fix

📚docsDocumentation only changes

💎styleChanges that do not affect the meaning of the code

♻️refactorA code change that neither fixes a bug nor adds a feature

⚡perfA code change that improves performance

✅testAdding missing tests or correcting existing tests

🏗️buildChanges that affect the build system or external dependencies

👷ciChanges to CI configuration files and scripts

🔧choreOther changes that don't modify src or test files

⏪revertReverts a previous commit

Benefits

Automatically generate CHANGELOGs
Automatically determine semantic version bump
Communicate nature of changes to teammates
Trigger build and publish processes
Make it easier for people to contribute

Best Practices

Keep the subject line under 100 characters
Use lowercase for type and description
Don't end the subject line with a period
Use imperative mood ("add" not "added")
Add blank line between subject and body
Wrap body at 72-100 characters
Use body to explain what and why vs. how

About Git Commit Message Linter

Conventional Commits give a commit history structure that tools can read: a type like feat or fix, an optional scope, a concise subject, and an optional body and footer. That structure is what powers automated changelogs, semantic version bumps, and fast history scanning. This linter checks a commit message against that specification and tells you exactly where it deviates.

Paste a message and the tool flags the common problems — a missing or unrecognized type, a subject that is too long, a capitalized or period-terminated subject, a missing blank line before the body, or a malformed breaking-change footer. Where the fix is mechanical, it rewrites the message into a compliant form so you can copy a clean version straight back into your editor or amend.

It is a useful learning aid as well as a checker. By showing what was wrong and what the corrected message looks like, it helps a team converge on a consistent style before wiring the same rules into a commit-msg hook or CI gate. Everything runs locally in your browser; commit text is never uploaded.

How to use Git Commit Message Linter

Paste your commit message
Drop the full commit message, including any body and footer, into the input area.
Review the findings
The linter lists each rule that passed or failed against the Conventional Commits specification.
Apply the suggested fix
Where the issue is mechanical, copy the auto-formatted message the tool produces.
Use it in your workflow
Adopt the corrected format and, if you like, enforce the same rules with a commit-msg hook or CI check.

Frequently asked questions

JSON Formatter · Beautifier · Validator

Format, minify, sort keys, and validate JSON/JSONC/JSON5 with optional JSON Schema validation. Supports comments and trailing commas.

Regex Highlighter

Highlight matching text in real-time using your custom regular expressions.

YAML Formatter · Beautifier · Validator

Format, beautify, minify, and validate YAML online. Supports YAML 1.1 and 1.2, multi-document files, JSON Schema validation, key sorting, and anchor/alias handling. Deterministic output with customizable indentation and line width.