Changelog generator
Updated
Write release notes in a form — version, date, and what was Added, Changed, Fixed — and get a CHANGELOG.md in the Keep a Changelog format with compare links. Or paste your git log and let conventional commits sort themselves into sections.
Unreleased notes
Releases (newest first)
# 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]
## [1.1.0] - 2026-09-03
### Added
- Dark mode toggle in settings
- `--json` flag for machine-readable output
### Fixed
- Crash when the config file is empty (#42)
## [1.0.0] - 2026-06-01
### Added
- Initial public release
[Unreleased]: https://github.com/you/my-project/compare/v1.1.0...HEAD
[1.1.0]: https://github.com/you/my-project/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/you/my-project/releases/tag/v1.0.0
my-project · 2 releases · Keep a Changelog 1.1.0
What goes in each changelog section?
Added for new features, Changed for changes to existing behavior, Deprecated for features that will be removed, Removed for features that are gone, Fixed for bugs, and Security for vulnerabilities. Write for the person upgrading, not the person who wrote the code: “Config files can now be YAML” rather than “refactor config loader”. One bullet per change, present tense, with a PR or issue number in parentheses when there is one to link to.
How do conventional commits map to changelog sections?
Conventional Commits prefix every message with a type — feat:, fix:, perf:, refactor:, docs:, chore: — with an optional scope in parentheses and a ! for breaking changes. That structure is enough to draft a changelog automatically: features become Added, fixes become Fixed, performance and refactoring become Changed. Housekeeping types like chore, ci, and test are excluded by default because users of your project do not care about them; toggle them on if your team does. Scopes are kept as a bold prefix so feat(cli): add --json becomes cli: Add --json.
Where does the changelog live?
At the repository root as CHANGELOG.md, next to the README — link to it from the README's install or contributing section so people can find it. The README generator and README templates cover the rest of the project's front door; the badge generator adds a version badge that always shows the latest release.
What is the Keep a Changelog format?
A convention for human-readable changelogs: a CHANGELOG.md with one ## [version] - YYYY-MM-DD heading per release, newest first, and bullets grouped under Added, Changed, Deprecated, Removed, Fixed, and Security. An [Unreleased] section at the top collects changes for the next version.
How do I generate a changelog from git commits?
Run git log --oneline <last-tag>..HEAD, paste the output into the "From git log" tab, and the tool groups Conventional Commits by type: feat becomes Added, fix becomes Fixed, perf and refactor become Changed, revert becomes Removed. Commits marked with ! or BREAKING CHANGE get a BREAKING label.
What are the compare links at the bottom of a changelog?
Reference-style links that turn each version heading into a link to the diff between that version and the previous one, such as https://github.com/owner/repo/compare/v1.0.0...v1.1.0. The first release links to its tag instead. Enter your repository URL and they are generated for you.
Should I use Semantic Versioning in the changelog?
Keep a Changelog recommends it: MAJOR for breaking changes, MINOR for new features, PATCH for fixes. The tool validates versions against the SemVer pattern, including pre-release suffixes like 2.0.0-beta.1.
Is my changelog uploaded anywhere?
No. Everything is generated in your browser. Only clicking "Share as link" publishes the markdown, to a URL with an edit token that expires after 30 days.