Free · Live

Is your commit message valid?

CommitCheck validates Conventional Commits format in real time — no Commitlint, no setup, no account.

Try an example:

Valid commit types

featA new feature
fixA bug fix
docsDocumentation only changes
styleFormatting, whitespace — no logic change
refactorCode change that is neither a fix nor a feature
testAdding or correcting tests
choreMaintenance — deps, config, tooling
perfA code change that improves performance
ciChanges to CI configuration files and scripts
buildChanges to the build system or dependencies
revertReverts a previous commit

Why use Conventional Commits?

  • Automated changelogs. Tools like release-please and semantic-release read your commit history to generate CHANGELOG.md entries automatically.
  • Semantic version bumps. feat commits bump the minor version. fix commits bump the patch. Breaking changes (! or BREAKING CHANGE footer) bump the major version — automatically.
  • Readable git history. A consistent format makes it easy to scan what changed and why, especially when narrowing down a bug introduction with git bisect.
  • Tooling compatibility. GitHub Copilot suggests it by default. Changesets, nx, turborepo, and most modern monorepo tools understand it natively.

Frequently asked questions

What is Conventional Commits?

Conventional Commits is a specification for writing structured Git commit messages. The format is: type(scope): description. It's widely adopted because it enables automated changelogs, semantic version bumps, and cleaner git history. Tools like semantic-release, release-please, and Changesets all depend on it.

How is CommitCheck different from Commitlint?

Commitlint is a CLI tool that enforces Conventional Commits in your repo via Git hooks. It requires installation, a config file, and a hook runner like Husky. CommitCheck is a zero-setup browser tool — paste a message, get instant feedback. Use Commitlint for enforcement in a team repo; use CommitCheck for quick checks or when learning the format.

Is the scope required?

No. Scope is optional. `feat: add login page` and `feat(auth): add login page` are both valid. Use scope when the change is scoped to a specific part of the codebase and that context helps readers understand the change.

How do I mark a breaking change?

Add an exclamation mark before the colon: `feat!: remove deprecated API` or `fix(auth)!: change token format`. You can also add a `BREAKING CHANGE:` footer in the commit body. Either approach works; the `!` is more visible in git log output.

What commit types are valid?

The standard types are: feat (new feature), fix (bug fix), docs (documentation), style (formatting only), refactor (code restructure), test (tests), chore (maintenance), perf (performance), ci (CI config), build (build system), revert (reverts a commit). Custom types are allowed by the spec but not recognized by most tooling.

Does CommitCheck work offline?

Yes. All validation runs entirely in your browser — there are no API calls. Once the page loads, it works without an internet connection.