A changelog generator that turns a raw commit log into release notes a human would actually read. Paste your commits, and they are grouped into Added, Changed, Fixed and Removed following the Keep a Changelog convention, with the noise stripped out. Export as Markdown for your repository or HTML for a release page.
No signupRuns in your browserNothing uploaded
Changelog GeneratorLive
This tool is built for a wider screen — scroll sideways inside the frame, or turn your device.
How to use it
Four steps to a result
Paste your commit log
Run git log --oneline for the range you are releasing and paste the output. Conventional Commit prefixes are recognised automatically.
Set the version and date
Enter the version number and release date. Semantic versioning is assumed, so a breaking change signals a major bump.
Review the grouping
Commits land under Added, Changed, Deprecated, Removed, Fixed or Security. Move anything that was filed wrong and delete the merge commits and typo fixes nobody needs to read.
Export the release notes
Copy the Markdown into CHANGELOG.md, or export HTML for a release page or an in-app What's New panel.
Questions
Frequently asked questions
Run git log --oneline v1.2.0..HEAD to list the commits since your last tag, then paste that output here. The commits are parsed, categorised and formatted into release notes you can paste straight into CHANGELOG.md.
It is the widely used convention where each release is a version heading with a date, and changes are grouped under Added, Changed, Deprecated, Removed, Fixed and Security. Consistent grouping is what makes a changelog scannable, which is the entire point of writing one.
No, but they help. If your commits are prefixed with feat:, fix:, perf: or refactor:, grouping is automatic and accurate. Without prefixes the categorisation is a best guess from the message text, and you will want to reassign a few entries by hand.
No. A changelog is written for the people who use your software, not for its maintainers — that is what git log is for. Drop merge commits, formatting-only changes and internal refactors that nobody outside the repository can observe.
Under semver, a breaking change requires a major bump, a new backwards-compatible feature a minor bump, and a bug fix a patch bump. Grouping your commits first makes the correct version number obvious: anything in Removed or a documented breaking change means major.
Keep going
More free tools
Every one runs in your browser, with no account and nothing uploaded.