What is the Keep a Changelog format?

Keep a Changelog is a widely adopted convention where each release has a version heading with a date, then grouped sections: Added, Changed, Deprecated, Removed, Fixed and Security. It is written for humans, newest entry first.

What version number should I use?

Follow Semantic Versioning: MAJOR.MINOR.PATCH. Bump MAJOR for breaking changes, MINOR for new backward-compatible features, and PATCH for backward-compatible bug fixes.

Are empty sections included?

No. The generator only outputs change-type sections that contain at least one bullet, keeping your changelog tidy and free of empty headings.

What date format does it use?

Keep a Changelog recommends ISO 8601, so dates are formatted as YYYY-MM-DD. If you leave the date field empty the tool fills in today's date in that format.

Where do new entries go?

Place the newest release at the top of the file, directly under the main CHANGELOG title and any Unreleased section, so readers see the latest changes first.

What is the CHANGELOG Entry Generator?

Generate CHANGELOG.md entries in the Keep a Changelog format with version, date and standard change-type sections (Added, Changed, Fixed, Removed, Deprecated, Security). Paste in your notes and copy clean Markdown. It runs free in your browser on Gera Tools, with nothing uploaded.

CHANGELOG Entry Generator

Name: CHANGELOG Entry Generator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Consistent release notes every time

The CHANGELOG Entry Generator formats your release notes into the Keep a Changelog standard so every entry looks the same. Inconsistent changelogs (mixed headings, missing dates, ad-hoc sections) make history hard to scan. Enter a version, a date and your bullets, and copy a clean Markdown block to drop into CHANGELOG.md.

How it works

Keep a Changelog defines a fixed structure: a version heading carrying the release date, then a set of standard sections in a recommended order. The generator builds the heading and emits only the sections you filled in:

## [1.4.0] - 2026-06-06

### Added
- New CSV export endpoint for Finance reports

### Changed
- Dashboard cards now refresh every 60 seconds instead of requiring a manual reload

### Fixed
- Crash when filtering on empty date ranges
- Team members with read-only access could incorrectly reach billing settings

Each non-empty section becomes a ### heading, and every line you type becomes a - bullet. The version is wrapped in square brackets per the convention so it can later be linked to a diff or a git tag.

The six section types and when to use each

Section	Purpose	Example
Added	New features that did not exist before	”Added bulk CSV export for date ranges”
Changed	Modifications to existing behaviour	”Default sort order is now newest-first”
Deprecated	Features that will be removed in a future release	”The v1 API endpoint is deprecated; use /v2/”
Removed	Features or APIs removed in this release	”Removed the legacy XML export option”
Fixed	Bug fixes	”Fixed empty chart when no data in range”
Security	Vulnerabilities patched	”Patched IDOR vulnerability in user settings API”

Empty sections are omitted from the output so the entry stays concise. A typical patch release has only “Fixed”; a minor release typically has “Added” and maybe “Changed.”

Tips for a useful CHANGELOG

One entry per version. Keep a Changelog puts the newest version at the top. Never edit a past entry — add corrections in the next release.
Maintain an Unreleased section. Add bullets as you merge, then rename [Unreleased] to the version on release day. This avoids scrambling for release notes at deploy time.
Bullets are for humans, not CI. Describe the impact on the user — “Fixed a crash when uploading files over 50 MB” — not the internal ticket or commit hash.
Link versions to diffs. At the bottom of CHANGELOG.md add comparison URLs like [1.4.0]: https://github.com/org/repo/compare/v1.3.0...v1.4.0 so readers can jump straight to the code changes.