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.

CHANGELOG Entry Generator

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

### Fixed
- Crash when filtering on empty dates

Each non-empty textarea becomes a ### section, 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 tag. The date defaults to today in ISO 8601 (YYYY-MM-DD).

Tips and notes

Version with SemVer: MAJOR for breaking changes, MINOR for features, PATCH for fixes.
Keep bullets user-facing — describe the impact, not the commit message.
Maintain an Unreleased section at the top so changes are recorded as you merge, then rename it on release.