The 5 best tools to auto-generate release notes from GitHub in 2026
Everything a release note says is already in your merged PRs. The tools that extract it differ on two things: how much discipline they demand from your commit and PR habits, and who the output is readable by — other developers, or the customers waiting on a fix.
We build Modem, one of the entries below; judge our ranking with that in mind. For the developer-facing changelog, the honest first answer is free and built into GitHub.
The short version
| Tool | Input it reads | Discipline required |
|---|---|---|
| GitHub auto-generated notes | Merged PRs | PR titles worth reading |
| release-drafter | Merged PRs + labels | Consistent labeling |
| semantic-release | Commit messages | Conventional commits, strictly |
| Modem | Merged PRs + captured requests | None on the repo side |
| Hosted changelog tools | Whatever you paste | Editorial time |
1. GitHub auto-generated release notes
GitHub can generate release notes automatically when you cut a release: a categorized list of merged PRs since the last tag, configurable by label, with first-time contributors called out. It's free, native, and exactly as good as your PR titles.
Where it fits: the default for any public repo or internal tool. Adopt it before evaluating anything else, if only to learn whether your PR titles are usable.
2. release-drafter
release-drafter maintains a rolling draft release: every merged PR is added to the draft as it lands, sorted into categories by label, and labels can infer the next semver version. When you ship, the notes are already written and a human just presses publish.
The draft-as-you-go model is its real advantage — release day stops being an archaeology session over six weeks of merges.
Where it fits: teams that release on a human schedule and want the notes accumulating between releases.
3. semantic-release
semantic-release automates the entire release: it parses conventional commit messages to determine the next version, generates notes via conventional-changelog, and publishes the package, all in CI with no human in the loop.
The cost is strictness. Every commit message becomes load-bearing, and the output reads like what it is: a machine-organized list of commits, written for developers.
Where it fits: libraries and CLIs on continuous release, with a team that will actually keep conventional commits honest.
4. Modem
The three tools above answer "what changed?" for people who read changelogs. Modem answers a different question: which customers should hear about this merge? Because Modem captures requests and bug reports from Slack, support, and email and links them to issues, a merged PR in a connected repo matches back to the people who originally asked. From that match it drafts release notes and per-customer follow-ups, so the loop closes from the merge event rather than from someone's memory. That request-to-merge thread runs through Modem's context graph, which keeps each person tied to the topics they raised across channels — the match is a join, not a search.
We build Modem, and to be clear about scope: it does not version your changelog or replace the developer-facing tools above — teams run it alongside them. If your GitHub issues come from customer reports in the first place, see our guide to turning customer feedback into GitHub issues.
Where it fits: product teams whose merges resolve customer requests, and who want requesters told automatically. Where it doesn't: open-source changelogs and version bookkeeping.
5. Hosted changelog tools
The last mile is publishing. Widget-and-page tools like Beamer or Frill host the customer-visible changelog but don't read your repo — a human curates what GitHub or release-drafter produced into announcement-worthy prose. We compare that category in our changelog tools guide.
Where it fits: as the publishing surface downstream of whichever generator above you pick, when your audience won't read a GitHub release page.
How to choose
Work backward from the reader. Developers pulling your package: semantic-release if your commit discipline is real, GitHub's native generation if it isn't. A team shipping weekly: release-drafter, so notes accumulate instead of piling up. Customers: no PR-derived text is customer-ready — either budget editorial time to rewrite it into a hosted changelog, or use the request-to-merge match to notify the people who asked directly. And note the shared failure mode of the mechanical tools: they can only describe changes in repo vocabulary. If nobody connected the PR to the customer problem it solves, no generator can put that in the notes — that context has to be captured before the merge, which is the part we build Modem around — on the Linear side as well as GitHub.
