Changelog Generator
A clear release history based on Keep a Changelog
-
1Enter data
Enter content, paste text or load a file from disk. -
2Click the button
The tool will immediately process your data in the browser. -
3Get the result
Copy the finished text or save the file to your device.
return "Result ready in 0.1s";
}
Removed and security
Keep a Changelog groups changes by their significance. Semantic versioning with MAJOR.MINOR.PATCH helps readers understand the scope of a release.
Rate this tool:
Related tools
Other tools you may find usefulCHANGELOG.md generator based on Keep a Changelog
The changelog generator turns short release notes into structured Markdown. Enter a version, date, and changes to create sections that follow the Keep a Changelog convention.
A useful changelog is not a raw copy of the commit history. It tells users, administrators, and integrators what to expect after an upgrade. This tool groups entries under Added, Changed, Deprecated, Removed, Fixed, and Security. Empty categories are omitted, leaving a concise result ready to paste into CHANGELOG.md.
How to prepare a release entry
- Enter a semantic version such as
1.4.0or2.0.0-beta.1. - Select the publication date in
YYYY-MM-DDformat. - Put each change on a separate line. A leading dash, asterisk, or plus sign is normalized.
- Keep the
[Unreleased]section enabled when the file should collect work planned for the next release. - Copy the result and place the newest version above older entries in the repository.
The Patch and Major buttons load safe examples, but they do not decide the release scope for you. If publishing is handled by CI, combine the generated entry with a workflow from the GitHub Actions generator or a pipeline from the GitLab CI generator.
Change categories and semantic versioning
What does each category mean?
| Section | When to use it | Example |
|---|---|---|
| Added | A new user-facing capability | CSV report export |
| Changed | Modified behavior that still exists | Faster result filtering |
| Deprecated | A feature still works but will be removed | Notice for an old API |
| Removed | A feature is no longer available | Removal of an unsupported option |
| Fixed | A bug or regression was corrected | Form validation fix |
| Security | A vulnerability was fixed or protection improved | Upgrade of a vulnerable dependency |
MAJOR, MINOR, and PATCH
SemVer represents a release as MAJOR.MINOR.PATCH. Increase MAJOR for an incompatible public API change, MINOR for a backward-compatible feature, and PATCH for a backward-compatible bug fix. The generator also accepts valid prerelease and build suffixes, including 2.0.0-rc.1 and 1.4.2+build.7. It cannot determine the impact of a change automatically; the project maintainer still owns that decision.
The version and date are validated, and control characters cannot create an extra heading. Each item has a practical length limit, while the result is displayed as text rather than executable HTML. Code fragments, branch names, and issue identifiers can therefore be described safely.
How to write entries readers can use
Describe the outcome instead of the developer activity. “Added CSV invoice export” is more helpful than “Merged PR #418.” Mention a migration, a new requirement, or a configuration change whenever the reader must take action. Keep implementation details in commits; consistent release automation can also be maintained with a Jenkinsfile generator.
Frequently asked questions
What is the Unreleased section?
It collects changes merged into the main branch but not included in a tagged release. When publishing, move the relevant items under a version and date, then leave an empty Unreleased section for future work.
Does the generator build the entire history?
It creates the file header and one release entry. Paste that fragment above older versions in an existing file. The tool never needs access to a private repository or its complete history.
Does the version have to start with v?
No. Both 1.2.3 and v1.2.3 are accepted. Consistency across repository tags, package metadata, and release pages matters more than either style.
Can a changelog be generated directly from commits?
Yes, especially when commit messages follow a strict convention, but the generated text still benefits from editorial review. User impact is rarely captured perfectly by a list of technical commits.
Where should CHANGELOG.md be stored?
Most projects put it in the repository root beside the README and license. Link to it from documentation and release pages so readers can quickly find upgrade and migration information.