Changelog Generator
Group Conventional Commits into a Keep a Changelog-style breakdown.
Paste commits on the left.
How it works
`semantic-release` and `standard-version` build a changelog from Conventional Commits by mapping each commit's
type to a Keep a Changelog section — this does the same mapping without needing to actually run a release tool
against a repository: feat → Added, fix → Fixed, perf/refactor
→ Changed, and any commit marked breaking (a ! or a BREAKING CHANGE: footer) goes into
its own section first, regardless of type.
Nothing that doesn't parse gets silently dropped
A line that isn't a valid Conventional Commit header is listed under "Unparsed" rather than excluded — a changelog missing a real change because its message didn't match a grammar is a worse failure than an ungrouped line asking you to look at it.
Types outside the mapping are counted, not hidden
docs, chore, ci, test, build and
style commits are real work but not user-facing changes, so Keep a Changelog has no section for them
— this tool reports how many were seen and skipped rather than pretending they weren't there.
Example
A feat!: remove the deprecated /v1 endpoint commit produces a "Breaking Changes" section ahead of
"Added" — breaking changes are the one thing a changelog reader needs to see before anything else, so this tool
orders the section first regardless of where the commit fell in the input.
Frequently asked questions
What happens to a commit that is not valid Conventional Commits?
It's listed under an "Unparsed" section verbatim rather than dropped. A changelog missing a real change because its message didn't match a grammar is a worse failure than one ungrouped line asking you to look at it.
Why do breaking changes get their own section first?
Because that's the one thing a changelog reader needs to see before anything else, regardless of which type the commit itself was. A feat!: commit is pulled into "Breaking Changes" ahead of "Added" rather than filed under its type and easy to miss.
Can it paste from full git log output, not just one-line subjects?
Yes — it reads a git commit's own convention that a body always follows its subject after a blank line, so a full git log dump with multi-paragraph bodies and footers splits into commits correctly rather than treating every line as a separate one.
Related tools
Commit Message Formatter
Validate a Conventional Commits message, or build one from separate fields.
LocalSemVer Comparator
Compare two versions using SemVer 2.0.0 precedence, not string sort.
LocalSemVer Range Checker
Check whether a version satisfies a range like ^1.2.0 or ~2.0.0.
LocalGit Diff Viewer
Render git diff output as a readable, colour-coded diff.
LocalGit Patch Parser
Parse git format-patch output into author, subject and diff.
LocalCSV Linter
Check a CSV file for ragged rows and detect its delimiter, without converting it to anything.
Local