How to write a changelog
Turn a list of changes into a clean, versioned changelog entry grouped by type — following the Keep a Changelog convention your users already understand.
A changelog is a kindness to your users: it tells them what changed without making them read commits. The Changelog Generator turns a rough list of changes into a clean, versioned entry in the widely understood Keep a Changelog format.
The format, and why it's standard
Keep a Changelog groups each version's changes by type:
## [1.2.0] - 2026-06-21
### Added
- Dark mode toggle
### Fixed
- Crash when opening empty files
### Changed
- Faster startup
The grouping is the value: a user scanning for "did they fix my bug?" jumps straight to Fixed. The categories are Added, Changed, Deprecated, Removed, Fixed, Security — a vocabulary readers learn once and recognize everywhere.
How to use it
List your changes, optionally prefixing each with its type (added:, fixed:, changed:…), set the version and date, and the tool produces the grouped entry. Unprefixed lines default to Added.
What makes a good entry
- Write for users, not commits. "Fixed a crash when opening empty files" beats "patch null check in loader."
- One change per line. Scannable beats comprehensive.
- Lead with impact. What the reader can now do, or no longer suffers.
Keep it at the top
New versions go at the top of CHANGELOG.md, newest first, so the latest is the first thing a reader sees. Add each version's entry as you release it, while the changes are fresh.
Privacy
Generation is local — your changes stay in the browser.
Give your users a changelog they can actually scan, one release at a time.