Changelog and Release Notes Generator
Free changelog generator in Keep a Changelog format. Add entries by type or paste conventional commits and get release notes as markdown.
# Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - Keyboard shortcuts for the editor ## [1.1.0] - 2026-08-20 ### Added - **export:** Export to PDF ### Changed - **BREAKING** Minimum supported Node.js version is now 20 ### Fixed - Crash when opening an empty file ## [1.0.0] - 2026-06-01 ### Added - Initial release [Unreleased]: https://github.com/example/widgets/compare/v1.1.0...HEAD [1.1.0]: https://github.com/example/widgets/compare/v1.0.0...v1.1.0 [1.0.0]: https://github.com/example/widgets/releases/tag/v1.0.0
What Is a Release Notes Generator?
A release notes generator is a tool that assembles the changes shipped in a version into a document users can read: what was added, what changed, what was fixed and what they must do before upgrading. This changelog generator produces two flavours of that document from the same data: a CHANGELOG.md in the Keep a Changelog format for the repository, and a GitHub-style release description with headings and a contributors placeholder for the Releases page.
You can type entries by hand in the editor, or paste the output of git log --oneline and let the conventional commits changelog mapping sort them into sections. Everything runs in your browser.
How to Generate a Changelog
- Enter the repository URL so the footer can link each version to a compare view.
- In the Editor, add entries under Unreleased or click Add version, set the number and date, and add entries with a type each.
- Or open From commits, paste
git log --oneline --decorate, and pick whether chore and ci commits are dropped. - Type a version number for the untagged commits if you are cutting a release, then click Open in editor to fine-tune wording.
- Copy or download CHANGELOG.md, or switch to Release notes and pick the version to publish on GitHub.
Conventional Commits to Keep a Changelog Sections
The commit parser reads the type before the colon and applies this mapping:
| Commit prefix | Changelog section | Notes |
|---|---|---|
| feat, feature, add | Added | New capabilities |
| fix, bugfix, hotfix | Fixed | Bug fixes |
| refactor, perf, docs | Changed | Behaviour or documentation changes |
| deprecate | Deprecated | Features slated for removal |
| revert, remove | Removed | Deleted features |
| security, sec | Security | Vulnerability fixes |
| chore, ci, build, style, test | dropped | Kept as Changed when the drop option is off |
| type! or BREAKING CHANGE: | same section, marked BREAKING | Listed first in release notes |
A scope in parentheses, such as feat(api):, is kept as a bold prefix on the entry.
Changelog vs Release Notes
A changelog is cumulative: one file, every version, newest first, written for developers who want to know exactly what changed between two tags. Release notes cover a single version and are written for users, so they lead with breaking changes and new features and end with the people who contributed. The Keep a Changelog output keeps the strict section order and link references, while the release notes output uses friendlier headings such as New features and Bug fixes and adds a Full Changelog compare link that GitHub renders under the release.
Why Use a Release Notes Generator on Every Tag
A release notes generator keeps the write-up honest because it starts from the commits rather than from memory. Run it when you tag: paste the log since the previous tag, drop the chores, give the version a number, and you have a CHANGELOG.md entry and a release description that agree with each other. Teams that already write conventional commits get a usable draft in seconds; teams that do not can still use the editor to type entries by type and get the same formatting.
Frequently Asked Questions
What does a release notes generator do?
A release notes generator turns a list of changes into a readable document for the people who use your software. This one takes entries you type or commits you paste, groups them into Added, Changed, Deprecated, Removed, Fixed and Security, and writes both a CHANGELOG.md and a GitHub release description.
What is the Keep a Changelog format?
Keep a Changelog is a convention for CHANGELOG.md files: a heading per version with its date in YYYY-MM-DD form, an Unreleased section at the top, entries grouped by change type, and link references at the bottom that point each version at a compare view. The generator follows version 1.1.0 of the spec.
How are conventional commits mapped to changelog sections?
feat becomes Added, fix becomes Fixed, refactor, perf and docs become Changed, revert becomes Removed and deprecate becomes Deprecated. A ! after the type or a BREAKING CHANGE footer marks the entry as breaking. chore, ci, build, style and test commits are dropped unless you untick that option.
Can it split commits into versions?
Yes. Paste the output of git log --oneline --decorate and every commit that carries a tag: vX.Y.Z decoration starts a new version; older commits fall under it until the next tag. Commits above the newest tag land in Unreleased, or in the version number you type.
Where do the compare links come from?
From the repository URL. The footer links Unreleased to a compare between the latest tag and HEAD, each version to a compare with the previous tag, and the first version to its release tag page. The links use the GitHub URL layout, which GitLab and Gitea also accept for compare views.
Is anything sent to a server?
No. The changelog generator parses commits and renders markdown entirely in your browser.