Drop any file to identify it
No upload. No signup. No sending your file halfway across the internet.
We tell you what it is, right here in your browser.
Drop it!
Let go to identify this file.
Couldn't identify this file
Need to convert it? fwip it →
The CHANGELOG file (often CHANGELOG.md, sometimes HISTORY.md or NEWS.md) documents the project's version history in a form humans can read. Each release gets a heading with the version number and date, followed by a list of changes grouped by type: Added, Changed, Deprecated, Removed, Fixed, Security. When a user asks "what's new in v2.4?" or "why did this break after I upgraded?", the CHANGELOG is the answer.
The industry standard format is Keep a Changelog (keepachangelog.com), which defines those six change categories and a release-note structure. Combined with semantic versioning (semver.org), the CHANGELOG becomes a contract: a major version bump means breaking changes (look for Removed/Changed entries), a minor bump means new features (Added), and a patch bump means bug fixes only (Fixed). Following this discipline pays off when users automate dependency updates — they can read the CHANGELOG and decide whether the upgrade is safe.
Many projects automate CHANGELOG generation from commit messages using tools like conventional-commits, release-please, or semantic-release. The trade-off: automated changelogs are always up-to-date and include nothing accidentally, but they read like commit logs rather than release notes. Hand-written changelogs are friendlier and more curated but require discipline to maintain. The best projects use automation as a starting point and edit the result before each release for clarity.
* Renders Markdown automatically