Users and developers both want to know what changed in a new version, but release notes written as a freeform paragraph are hard to scan and harder to compare between versions. The Keep a Changelog convention solves this with a simple structure: one heading per version with a date, and grouped lists for added features, changes, deprecations and fixes. This generator turns your raw notes for a release into that exact format, so every release entry looks consistent whether it was written today or a year ago. Consistent changelogs build trust, because users can see at a glance whether an update is safe to install or whether it changes behaviour they depend on.
Quick Answer: Enter the version, date and your Added, Changed and Fixed items, then click Generate Changelog to get a formatted release entry.
Free Online Tool
Changelog Generator
Format a release entry the Keep a Changelog way.
How to Use the Changelog Generator
- Enter the version number for the release, such as 1.2.0, without any extra prefix.
- Enter the release date in year month day form so entries sort and read consistently.
- List the new features under Added, one item per line, in plain language.
- List behaviour changes under Changed and bug fixes under Fixed, again one item per line.
- Click Generate Changelog and copy the formatted entry into your CHANGELOG file above older entries.
Key Features
- Keep a Changelog structure with a version heading, a date, and grouped change categories.
- Separate Added, Changed and Fixed sections, so readers can distinguish features from fixes instantly.
- Automatic omission of empty sections, keeping each entry tight and free of placeholder headings.
- Markdown output that renders correctly on hosting platforms and in documentation sites.
- Newest first ordering guidance, matching the convention of placing the latest release at the top of the file.
Best Practices and Tips
- Write changelog items for users, not for developers: describe what changed in behaviour, not which internal function was edited.
- Mention breaking changes prominently in the Changed section, since that is where upgraders look first.
- Keep a running unreleased section during development, then rename it to the version number on release day.
- Date every entry. An undated changelog is much harder to correlate with support tickets and bug reports.
Common Mistakes to Avoid
- Mixing new features and bug fixes in one list, which forces readers to guess how significant a release is.
- Writing entries in developer jargon that users cannot map to anything they experienced in the product.
- Forgetting to add the entry entirely, and relying on commit messages that nobody outside the team will ever read.
Frequently Asked Questions
What is Keep a Changelog?
Keep a Changelog is a widely adopted convention for changelog files. It specifies one section per version, headed by the version number and date, with changes grouped under headings such as Added, Changed, Deprecated, Removed, Fixed and Security. Following it makes your changelog predictable for anyone who has seen one before.
Should the newest version go first or last?
Newest first. Readers almost always want the latest changes, and placing them at the top means they never have to scroll through years of history. Older entries stay below in reverse chronological order as a complete record.
How is a changelog different from commit history?
Commit history records every small step a developer took, including work in progress and reverts. A changelog is a curated summary for the audience of the software, grouping related commits into understandable changes and omitting internal detail that does not affect users.
What belongs in the Fixed section?
Bug fixes that change observable behaviour for the better: crashes resolved, incorrect outputs corrected, and broken features restored. Internal refactors with no user visible effect do not need a changelog entry at all.