Developer · Browser tool
Turn commit messages into release notes
CHANGELOG.md
Keep a Changelog format, updates as you typeLines without a Conventional Commits prefix carry a “check this grouping” comment. Read those before you publish.
- Free, no job limit
- No account
- Runs in your browser, nothing is uploaded
- Up to 400 messages per run
More from the same paste
Everything below comes from the log in the box above and changes when you edit it.
GitHub release body
A shorter version for a release page or a customer update. Internal refactoring, housekeeping and scope names are left out.
Filtered out
Nothing disappears without being listed. Every dropped line appears here with the reason, such as merge commit, version bump or typo fix.
What each line became
Anything marked needs review had no Conventional Commits prefix, so the group was picked from the wording.
One clear job, from log to release note
- 1
Paste the range
One item per line. A raw git log output works, and so does a list of merged pull request titles copied from a milestone. Hashes, dates and author names are ignored, so you do not need to clean the list first.
- 2
Check the grouping
Entries land under Added, Changed, Fixed or Removed. Noise is dropped and listed with the reason, so you can see what was thrown away. Lines without a Conventional Commits prefix are marked for review, because their group was picked from the wording.
- 3
Copy two versions
The long Markdown block goes into CHANGELOG.md. The short version drops into a GitHub release body or a customer-facing update post, where most of the internal refactoring is not worth mentioning.
Turning commit messages into a changelog draft
Your commit messages go in
You paste commit subjects, merged pull request titles or the raw output of git log, one item per line. One run takes up to 400 messages. Commit IDs, author names and dates are ignored, while bodies and footers are read when you include them. Conventional Commits prefixes such as feat and fix map straight onto sections. Without them the tool reads the wording, which works for descriptive messages and poorly for ones like update code.
The Markdown changelog and the skipped list
You get a Markdown changelog grouped into Added, Changed, Fixed and Removed, ready to copy or download. Merge commits, version bumps, lockfile updates, formatting-only changes and throwaway subjects like wip are left out. Everything dropped is listed under a skipped heading, so you can put an entry back if it mattered. The tool runs in your browser, free with no account and no job limit.
What you still check before you tag
The tool reads only the messages you paste, never the code changes. A removed parameter or a renamed config key stays invisible unless the commit says so or carries a BREAKING CHANGE footer. Add those by hand. Treat the output as a first draft. Check that every user-visible change is there, rewrite entries that use internal names, and add a sentence where people will need to act.
Questions before you run it
Do my commits have to follow Conventional Commits?
No, but the result is more accurate when they do. A prefix like feat, fix or refactor maps straight onto a changelog section, so grouping becomes mechanical rather than a guess. Without prefixes the tool reads the wording of each message, which works well for descriptive messages and poorly for ones like update code.
Can it tell whether a change is breaking?
Only if the message says so. The tool reads the text you paste, never the diff, so a removed parameter or a renamed config key stays invisible unless the commit mentions it or carries a BANG marker or a BREAKING CHANGE footer. Mark breaking work in the commit, or add it by hand afterwards.
What exactly should I paste in?
One item per line: commit subjects, merged pull request titles, or the raw output of a command such as git log v2.3.0..v2.4.0 --oneline. Hashes, author names and dates are ignored. Bodies and footers are read when you include them, which helps for breaking change notes.
Which messages get filtered out?
Merge commits, version bumps, lockfile updates, formatting-only changes and throwaway subjects such as wip, fix typo or asdf. Anything dropped is listed separately under a skipped heading so you can put something back if it mattered.
Should I publish the output without reading it?
No. Treat it as a first draft. A generated entry can misjudge how important a change was, and it cannot know about work that never landed in a commit message. Read it, fix the wording, and check that every user-visible change is really there before you tag the release.