Changelog Generator

Overview

Turns a list of commit messages into a Keep a Changelog style release entry. Conventional Commits prefixes are recognized and sorted into five groups: Breaking Changes, Features, Bug Fixes, Performance, and Dependencies & Chores. You supply the version number; the tool stamps today's date, formats the groups as markdown headings with bulleted entries, and lets you copy the result in one click.

How It Works

Paste commit messages into the text area, one per line, in forms like feat(auth): add OAuth2 flow or fix: null crash on save. Enter the version you are releasing, such as 1.4.0. The markdown builds live: a ## [version] - YYYY-MM-DD header, then a ### heading per non-empty group with each message as a list item. A commit marked with ! after the type or scope, like feat(ui)!: redesign navigation, is filed under Breaking Changes and flagged in bold. Lines that do not parse as conventional commits fall into the chores group rather than being discarded, and the copy button grabs the whole document.

Step-by-Step Usage Guide

1. Paste your commit messages into the input, one commit per line.
2. Type the release version into the version field, or the word Unreleased.
3. Check the groupings, moving anything odd by editing the source line's type prefix.
4. Copy the generated markdown into your CHANGELOG.md under the previous release.

Technical Specifications & Standards

The parser implements the core of the Conventional Commits 1.0.0 grammar: a type, an optional parenthesized scope, an optional exclamation mark, a colon, and the message. The type keyword decides the bucket: anything starting with feat goes to Features, fix to Bug Fixes, perf to Performance, and every other type such as chore, docs, style, refactor, or test lands in Dependencies & Chores, which is also where unparseable lines end up so nothing is silently lost. Two breaking-change signals exist in the wild and only one is fully honored here: an exclamation mark is detected and moves the commit to Breaking Changes, but a standalone BREAKING CHANGE: footer line submitted as its own input line parses as a type named BREAKING, which falls into the chores bucket. If your workflow writes breaking notices as footer lines, merge them into the commit header with an ! before pasting. The date is generated from the client clock at render time in YYYY-MM-DD format, matching the Keep a Changelog convention, and the Unreleased section that the convention recommends is not generated; rename the version field to Unreleased if you want that shape.

Targeted Use Cases

• Assembling a release note from a week of merged pull request squash commits.
• Normalizing mixed-style commit logs into a consistent Keep a Changelog document.
• Preparing a semver-bump justification by showing reviewers the breaking changes group.
• Generating a first changelog for an open source project before publishing a release.

Notes & Gotchas

• Write commits in conventional format before pasting; the grouping is only as good as the type prefixes.
• Mark breaking commits with ! on the header line rather than relying on a footer line, which is not classified as breaking here.
• Review the chores bucket, because unrecognized types and typos land there instead of failing loudly.
• Edit the date if you backfill a release; the stamp always reflects the day you generated the entry.

Frequently Asked Questions