// open source tooling

Keep a Changelog Format Generator

Turn your commits into a CHANGELOG.md that follows the Keep a Changelog standard — the right categories, in the right order, with semantic versioning.

What "Keep a Changelog" actually specifies

Keep a Changelog is a widely adopted convention for CHANGELOG.md files. Its whole point is consistency: every project that follows it looks familiar, so a contributor landing on your repo already knows where to look. The spec is opinionated about a few things, and getting them right is what makes a file "compliant" rather than just markdown with headings.

The core rules: entries are newest-first, every release has a version and an ISO date (2026-06-01), changes are grouped into a fixed set of categories, and there's an [Unreleased] section at the top for changes that have landed but aren't shipped yet.

The six categories

Added
New features or capabilities that didn't exist before.
Changed
Changes to existing behaviour that already worked.
Deprecated
Features still present but on their way out — a heads-up.
Removed
Features taken out in this release.
Fixed
Bug fixes.
Security
Vulnerabilities patched — call these out clearly.

You only include the categories that apply to a given release. A patch release might have nothing but a Fixed section, and that's correct.

How semantic versioning fits

Keep a Changelog pairs naturally with semantic versioning (MAJOR.MINOR.PATCH). The category of your changes signals the bump: anything under Removed or a breaking Changed means a MAJOR bump; new Added features are a MINOR bump; a release that's only Fixed is a PATCH. Keeping the two in sync means your version number alone tells users how risky an upgrade is.

A compliant example

CHANGELOG.md
## [Unreleased] ## [1.4.0] - 2026-06-01 ### Added - Streaming output for large changelogs - TypeScript type definitions in the published package ### Changed - Default request timeout raised from 10s to 30s ### Fixed - Memory leak under sustained concurrent use ## [1.3.2] - 2026-05-12 ### Security - Patched a ReDoS in the commit parser (low severity)

Note the [Unreleased] header sitting empty at the top, ready for the next change — and the version numbers reading top-to-bottom as a clean history.

Generate it from your commits

Writing this by hand for every release is exactly the kind of repetitive formatting work that's easy to get slightly wrong. Paste your git log into ChangelogAI, choose the Keep a Changelog format, and it produces the structure above — categories sorted, dates formatted, lines rewritten from commit-speak into readable entries. Copy it straight into your CHANGELOG.md.

FAQ

Do I need all six categories every release?

No. Include only the ones that apply. A bug-fix-only release legitimately has just a Fixed section.

What date format does the standard use?

ISO 8601 — YYYY-MM-DD, e.g. 2026-06-01. It sorts correctly and avoids the day/month ambiguity of other formats.

What's the [Unreleased] section for?

It's a holding area at the top for merged-but-unshipped changes. On release day you rename it to the new version and date, then start a fresh empty Unreleased section.

Is this only for open source?

No — it suits any project that wants a consistent, scannable history. It's especially common in open source because contributors benefit from the shared convention. For the broader principles, see how to write a changelog.

Generate a compliant CHANGELOG.md

Paste your commits, pick Keep a Changelog, and copy the result into your repo. No account needed.

try free →