About this tool
Every piece of software changes, and users deserve to know how. A changelog is the record of those changes, written for humans rather than buried in commit messages. When a new version of an app appears, the first thing a careful user checks is what is new, what is fixed and what might break. A good changelog answers those questions in seconds, in plain language, without forcing anyone to read code. Projects that keep one build trust, because their users never feel ambushed by a silent change.
ChangeLog is a free changelog generator for developers, product teams and open-source maintainers. You enter your version number, add entries grouped by type, such as Added, Fixed, Changed or Deprecated, and the tool assembles a clean, properly formatted changelog. The output follows the widely used Keep a Changelog style, with a heading for each version and grouped entries beneath it, so it drops straight into a CHANGELOG.md file or a release notes page without reformatting.
Version numbers carry meaning, and ChangeLog helps you use them correctly. Semantic versioning, or semver, uses three numbers: major, minor and patch. A patch bump means a backwards-compatible bug fix, a minor bump means new functionality that stays compatible, and a major bump means a breaking change. ChangeLog includes a version bump helper: tell it your current version and the kind of change you made, and it suggests the next version number, so you never have to guess whether a release should be 2.4.2 or 3.0.0.
Writing changelog entries well is a skill, and the rules are simple. Write for the user, not for yourself: say what changed in the product, not which function you edited. Use the past tense or the imperative consistently, keep each entry to one line, and group related changes together. Compare a bad entry such as fixed stuff in auth with a good one such as fixed login failures for accounts with two-factor authentication enabled. The second version tells a user whether the fix matters to them, and that is the whole test.
Grouping entries by type is what turns a list into a readable document. Added covers new features, Changed covers changes to existing behaviour, Deprecated warns about features that will be removed, Removed lists what is gone, Fixed covers bug fixes, and Security covers vulnerability fixes. Readers scan the headings first, so a user looking for security fixes can find them without reading every feature announcement. ChangeLog keeps these groups in a sensible order automatically, even if you add entries in a different order.
Unreleased sections deserve special attention. Most teams keep an Unreleased heading at the top of their changelog and add entries there as work lands, then rename it to a version number on release day. This habit prevents the classic failure where release notes are written from memory a week later and half the changes are forgotten. ChangeLog supports this workflow directly: start with Unreleased, add entries as you go, and when you are ready, set the version and date and the tool formats the release heading for you.
Release dates matter more than people think. A changelog without dates makes it impossible to answer simple questions, such as whether a bug existed in the version a customer was running, or how long a deprecated feature has been on notice. ChangeLog attaches the current date to each release by default, in ISO format, which sorts correctly and reads unambiguously around the world. If you are backfilling an old release, you can set the date yourself before exporting.
Changelogs also serve a legal and practical purpose for security fixes. When a vulnerability is fixed, users need to know which versions are affected and which version contains the fix, so they can upgrade with confidence. A Security section that names the issue plainly, without exaggeration, helps administrators prioritise. ChangeLog keeps security entries prominent and separate from feature announcements, so an urgent fix is never buried under a list of new buttons and colours.
Open-source projects gain credibility from a maintained changelog. Contributors can see that releases are deliberate, users can decide whether to upgrade, and downstream packagers can write accurate release notes of their own. Many projects link their changelog from the README, and some package registries display it alongside the package. ChangeLog exports clean Markdown with proper headings, which renders beautifully on GitHub, GitLab and documentation sites without any extra tooling or plugins.
Teams sometimes ask whether a changelog should duplicate the release notes on a blog or a store page. The answer is that the changelog is the durable record, while blog posts are announcements. A blog post can highlight three exciting features; the changelog must list everything, including the unglamorous fixes, because someone debugging a problem six months later needs the complete record. ChangeLog is built for completeness: it is easy to add the small fixes, and the export includes them all, in order.
Consistency across releases is what makes a changelog trustworthy over years. Use the same entry types, the same tense and the same heading format every time, and readers will learn to scan it quickly. ChangeLog enforces that consistency by generating the structure for you: you supply the content, the tool supplies the format. If your project already has a changelog in a different style, you can still use the generator for new releases and keep the older history untouched below the new entries.
Start small and start now. Create an Unreleased section, add the changes from your last week of work, and publish it with your next release. Your future self will thank you when a user asks what changed in version 2.3, and you can answer with a link instead of a memory. Good changelogs are not extra paperwork; they are the difference between a project that feels maintained and one that feels abandoned, and they cost only a few minutes per release when the tool does the formatting.
Finally, remember to write the changelog before you release, not after. Drafting entries as you work keeps them accurate, and reviewing the Unreleased section before a release is a useful final check: if the list looks thin, perhaps the release is not ready, and if it contains a breaking change you forgot, you have caught it in time to bump the major version. That discipline, repeated release after release, is what turns a simple document into a habit your whole team can rely on.
Migrating an old project to a proper changelog is easier than it looks, and it is worth doing even if the early history is incomplete. Create a new section for the current version, add entries for recent changes from memory and from recent commits, and leave older releases as a short summary rather than inventing detail you cannot verify. From that point forward, keep the Unreleased section current, and the document will grow accurate from today onward. Readers forgive a thin early history far more readily than they forgive a changelog that stops being updated, because a living document signals a living project.
One last habit completes the system: link the changelog from your README and your release page, so users actually find it. A changelog nobody can find helps nobody, however well written it is.
Frequently asked questions
What is a changelog?
A changelog is a human-readable record of the notable changes in each version of a project, grouped by type such as Added, Fixed or Changed.
What is semantic versioning?
Semantic versioning uses major.minor.patch numbers: patch for compatible bug fixes, minor for compatible new features, and major for breaking changes.
How do I use the version bump helper?
Enter your current version, choose patch, minor or major, and the tool suggests the next version number following semver rules.
What should go in the Unreleased section?
Add entries there as work lands, then rename it to a version number on release day so nothing is forgotten.
Can I export the changelog as Markdown?
Yes. The export is clean Markdown in Keep a Changelog style, ready to paste into CHANGELOG.md or release notes.
Is ChangeLog free?
Yes. ChangeLog is free with unlimited usage and no sign-up.