Add entries and categorize each one. Order matters — entries appear grouped by type.
Ready to generate
Fill in version, add entries, click Generate// turn commits into structured changelogs instantly
Generate structured, professional changelogs from your commit messages or release notes. Browser-based, free, no sign-up required.
Add entries and categorize each one. Order matters — entries appear grouped by type.
Ready to generate
Fill in version, add entries, click GenerateEnter your release version (e.g. 2.1.0) and the release date.
Click "Add Entry", type your change, and pick a category: Added, Fixed, Changed, etc.
Click Generate Changelog to get Markdown or plain text output. Copy or download instantly.
The Changelog Generator creates structured release notes following the Keep a Changelog convention. Entries are automatically grouped by type — Added, Changed, Fixed, Deprecated, Removed, and Security — so your changelog is always consistent and readable.
Keep a Changelog is a convention for writing changelogs in a human-readable, consistent way. It groups changes by type (Added, Changed, Fixed, etc.) under each versioned release, following Semantic Versioning.
The generator supports six standard types: Added (new features), Changed (changes to existing behavior), Deprecated (soon-to-be removed features), Removed (removed features), Fixed (bug fixes), and Security (security patches).
Currently the tool generates one version block at a time. You can generate multiple blocks separately and combine them in your CHANGELOG.md file — simply prepend each new version above the previous ones.
Semantic Versioning (semver) uses the format MAJOR.MINOR.PATCH — e.g. 2.1.0. MAJOR increments for breaking changes, MINOR for new backward-compatible features, and PATCH for backward-compatible bug fixes.
Yes. The Markdown output can be pasted directly into GitHub Release notes or a CHANGELOG.md file in your repository. The plain text format works for email announcements or internal docs.
No. All processing happens in your browser and on our server only to generate the output. We do not store, log, or share any of the content you enter into this tool.
A changelog generator is a tool that helps software developers, product managers, and open source maintainers create structured, consistent release notes from a list of changes. Instead of manually formatting your changelog every time you ship a new version, you simply enter your version number, release date, and the list of changes — and the generator produces a properly formatted changelog document in seconds.
This tool follows the widely adopted Keep a Changelog convention (keepachangelog.com), which defines a clear structure for changelogs that is both human-readable and machine-parseable. It also integrates naturally with Semantic Versioning (semver.org), the standard version numbering system used by most modern software projects.
A well-maintained changelog serves multiple audiences. For end users, it communicates what has changed between versions and whether an update includes features they've requested or fixes for bugs they've encountered. For developers integrating your library or API, the changelog is critical for understanding breaking changes before upgrading. For your team, it provides an audit trail of what shipped and when.
Projects without changelogs often frustrate contributors and users who must dig through commit history or pull request logs to understand what changed. A readable, consistently formatted changelog is a sign of a mature, professional project.
The Keep a Changelog format, created by Olivier Lacan, structures release notes around six entry types:
By grouping entries this way, readers can quickly scan for the category most relevant to them — a QA engineer may care most about Fixed entries, while an architect evaluating an upgrade needs to read Changed and Removed carefully before proceeding.
Changelogs pair naturally with Semantic Versioning (semver). The version number format MAJOR.MINOR.PATCH carries implicit meaning:
When your changelog entry types align with your version bump, users immediately understand the risk profile of an upgrade without reading every line. A PATCH release with only Fixed entries is low-risk. A MAJOR release with Removed and Changed entries requires careful review.
The quality of your changelog depends on the quality of your individual entries. Here are some practical guidelines:
These three documents serve different purposes and different audiences. Commit history is for contributors and is typically terse, technical, and exhaustive — every single commit appears. Release notes are marketing-adjacent documents that highlight the most exciting or important changes in a release, often written in a more narrative or promotional tone. Changelogs sit between the two: comprehensive enough to capture all user-facing changes, structured enough to be scanned quickly, but written in plain language accessible to non-contributors.
The Keep a Changelog convention is specifically designed for changelogs. It is not a replacement for release notes or documentation — but it is an essential companion to both.
This free, browser-based tool makes it easy to produce a properly formatted changelog block for any release. Enter your project name (optional), version number, and release date. Then add your changelog entries one by one, selecting the appropriate type for each. When done, click Generate to produce either Markdown output (suitable for CHANGELOG.md files on GitHub, GitLab, or Bitbucket) or plain text (suitable for email announcements or documentation systems that don't support Markdown).
The tool runs entirely in your browser with server-side generation — no data is stored, no account is required, and the output is yours to use immediately. Copy it to your clipboard with one click, or download a .md or .txt file directly.