CHANGELOG Entry Builder

Generate structured CHANGELOG.md entries in Keep a Changelog, Conventional Commits, or Simple format.

Generated CHANGELOG
Fill in the version and entries above to generate your changelog.

How to Use the CHANGELOG Entry Builder

  1. Choose a format — Keep a Changelog for structured category-based entries, Conventional for commit-message parsing, Simple for a plain bulleted list, or Append to add a new release to an existing file.
  2. Enter your version number — use Semantic Versioning (e.g. 2.1.0). The date defaults to today.
  3. Add your entries — in Keep a Changelog mode, click each section to expand it and type entries one by one. In Conventional mode, paste raw commit messages and the tool auto-categorises them.
  4. Copy or download — the output updates live. Download it as CHANGELOG.md or copy directly.

What is a CHANGELOG?

A CHANGELOG (or change log) is a file that documents all notable changes made to a project between each release. It is one of the most important files in any software project — developers need it to understand what changed between versions before upgrading a dependency, and end-users rely on it to see what bugs were fixed or features were added. A well-maintained CHANGELOG builds trust and reduces support burden.

Keep a Changelog Format

The Keep a Changelog specification, created by Olivier Lacan, defines six standard change categories:

  • Added — new features
  • Changed — changes in existing functionality
  • Deprecated — soon-to-be removed features
  • Removed — features removed in this release
  • Fixed — bug fixes
  • Security — vulnerability fixes

Each version section is a second-level heading: ## [2.1.0] - 2026-03-22. An ## [Unreleased] section at the top collects work in progress. This format is recommended by many open-source projects including npm, Composer, and Homebrew packages.

Conventional Commits

The Conventional Commits specification defines a lightweight commit message convention. Each message starts with a type — feat, fix, docs, chore, refactor, perf, test, ci, build, or style — optionally followed by a scope in parentheses and an exclamation mark for breaking changes. Tools like semantic-release and standard-version parse these messages to automatically bump the version number (feat = minor, fix = patch, feat! = major) and generate a changelog. This builder parses the same convention so you can go from raw git log output to a polished CHANGELOG entry in seconds.

Semantic Versioning Quick Reference

SemVer uses three numbers: MAJOR.MINOR.PATCH. Increment MAJOR when you make incompatible API changes, MINOR when you add functionality in a backward-compatible manner, and PATCH when you make backward-compatible bug fixes. Pre-release versions (1.0.0-alpha.1) and build metadata (1.0.0+build.20260322) are appended after a hyphen or plus respectively. The SemVer Comparator tool can help you compare versions and plan your next increment.

Best Practices

  • Write entries for humans, not compilers — explain what changed and why, not how.
  • Keep an [Unreleased] section while developing, then rename it when you cut a release.
  • Date every release in ISO 8601 format (YYYY-MM-DD) for unambiguous international reading.
  • Link version numbers to your repository's compare URL so readers can browse the actual diff.
  • Never rewrite or remove old changelog entries — they are a historical record.

Frequently Asked Questions

Keep a Changelog (keepachangelog.com) is a standard format for maintaining a CHANGELOG.md file. It groups changes under version headings, each dated, and categorises entries as Added, Changed, Deprecated, Removed, Fixed, or Security. The format is human-readable and machine-parseable.
Conventional Commits is a specification for commit messages that makes them machine-readable. Messages follow the pattern type(scope): description — for example feat(auth): add OAuth login. Tools like semantic-release and standard-version use Conventional Commits to automatically determine version bumps and generate changelogs.
Switch to the 'Append' mode, paste your existing CHANGELOG.md content into the 'Existing changelog' textarea, then fill in the new version details. The tool places the new version section at the top (below the title) and preserves all older entries.
Use Semantic Versioning (SemVer): MAJOR.MINOR.PATCH, e.g. 2.1.0. MAJOR bumps for breaking changes, MINOR for new backward-compatible features, PATCH for bug fixes. Pre-release identifiers like 1.0.0-alpha.1 or build metadata like 1.0.0+build.123 are also valid SemVer.
No. This tool runs entirely in your browser. No data is transmitted, logged, or stored anywhere outside your device.