AnyTool
Your files never leave your device. All processing happens locally in your browser.

How do I create a CHANGELOG.md in the Keep a Changelog format?

Open AnyTool Changelog Generator, keep an [Unreleased] section for merged-but-unreleased changes, then add versioned releases — each with a version number, an ISO date that defaults to today, and an optional “yanked” flag. Under every version, add entries to the six canonical groups: Added, Changed, Deprecated, Removed, Fixed and Security. One-click Major / Minor / Patch buttons bump the version following Semantic Versioning, and the engine assembles a compliant CHANGELOG.md — newest release first, empty groups dropped — with optional GitHub compare links. Copy the Markdown or download CHANGELOG.md; a rendered HTML preview shows how it looks, and everything runs in your browser, nothing uploaded.

  • Keep a Changelog 1.1.0 layout: an [Unreleased] section plus dated releases newest-first
  • Six change groups — Added, Changed, Deprecated, Removed, Fixed, Security — empty ones omitted
  • Semantic Versioning Major / Minor / Patch bump buttons and a today-defaulted date
  • [YANKED] marker for pulled releases and optional GitHub [Unreleased]/[x.y.z] compare links
  • Live Markdown output and a rendered HTML preview — 100% in your browser, nothing uploaded

What is

Changelog (CHANGELOG.md)

A changelog is a curated, chronologically ordered list of the notable changes made to a project for each of its versions. In the widely used Keep a Changelog convention it is stored as a CHANGELOG.md file with an [Unreleased] section at the top and one entry per released version (## [x.y.z] - YYYY-MM-DD), newest first, where changes are grouped as Added, Changed, Deprecated, Removed, Fixed and Security so people — not machines — can quickly see what changed and why.

Generators

Related terms

Keep a ChangelogSemantic Versioning (SemVer)Release notesCHANGELOG.md

Frequently Asked Questions

An [Unreleased] section at the top, then one dated entry per version newest-first, with changes grouped as Added, Changed, Deprecated, Removed, Fixed and Security.

Keep a Changelog defines a simple structure: a title and short intro, an [Unreleased] section that collects merged changes not yet shipped, and below it one section per released version written as “## [x.y.z] - YYYY-MM-DD” in reverse-chronological order. Within each version, changes are grouped into six types — Added for new features, Changed for changes in existing functionality, Deprecated for soon-to-be-removed features, Removed for now-removed features, Fixed for bug fixes, and Security for vulnerabilities. AnyTool Changelog Generator gives you exactly these groups for the Unreleased bucket and every version, and drops any group you leave empty.

Major / Minor / Patch buttons compute the next version following Semantic Versioning — major resets minor and patch to zero, minor resets patch.

Each release has Major, Minor and Patch buttons that apply Semantic Versioning rules to the current number: bumping the major increments the first number and resets the others to zero (for breaking changes), bumping the minor increments the middle number and resets the patch (for new, backward-compatible features), and bumping the patch increments the last number (for backward-compatible bug fixes). The tool suggests the next number, but you decide which kind of change you made — semver is about the nature of the change, not something a tool can infer for you.

No. The CHANGELOG.md is assembled entirely in your browser. Nothing you type is sent to a server, logged or stored.

AnyTool Changelog Generator runs completely client-side. Every keystroke updates the Markdown output and the rendered HTML preview locally, with no server round-trip, so your versions, dates and entry text never leave your device. The optional GitHub compare links are built as plain text from the owner and repository name you enter — they are not requested by the tool. The page works offline once cached, and closing the tab discards your draft.

It collects changes that are merged but not yet shipped; at release time you rename it to the new version with the release date.

Keep a Changelog recommends an [Unreleased] section at the very top so contributors can record changes as they land, before a release is cut. When you publish a release, those entries move into a new dated version section and a fresh, empty [Unreleased] takes its place. The generator keeps a persistent Unreleased bucket with the same six change groups, and the “Add version” button helps you snapshot it into a new release with a today-defaulted date and a suggested next version number.

Detailed Explanation

Methodology

How the Changelog Generator Builds the File

AnyTool Changelog Generator models a CHANGELOG.md in the Keep a Changelog 1.1.0 convention: a title and intro, a persistent [Unreleased] section, and a list of released versions. Each version carries a semantic version number, an ISO 8601 date (defaulting to today, supplied by the page so the engine stays clock-free), an optional “yanked” flag, and the six canonical change groups — Added, Changed, Deprecated, Removed, Fixed and Security. A pure, unit-testable assembly function emits the header, the Unreleased block, then every version newest-first as “## [x.y.z] - YYYY-MM-DD”, rendering only the change groups that contain entries and appending “[YANKED]” to pulled releases. Empty groups and empty versions collapse cleanly, and the output is a single, valid Markdown document.

  • Keep a Changelog 1.1.0 structure: header, [Unreleased], then dated releases newest-first
  • Six change groups per version — Added, Changed, Deprecated, Removed, Fixed, Security
  • Empty change groups are omitted; pulled releases get a [YANKED] marker
  • The engine is clock-free — the page supplies every date (today by default)
  • All assembly is pure client-side JavaScript — no server round-trip
Technical Details

Semantic Versioning Bumps and GitHub Compare Links

Every release has one-click Major / Minor / Patch buttons that apply Semantic Versioning rules to the current number — bumping the major resets the minor and patch to zero, bumping the minor resets the patch, and bumping the patch increments the last component, with any pre-release or build metadata dropped to a clean x.y.z core. The tool suggests the next number but leaves the judgement of breaking-vs-feature-vs-fix to the author. When a GitHub owner and repository name are provided, an optional link-reference section is built at the bottom: “[unreleased]” compares the newest tag to HEAD, each version compares against the previous tag (…compare/vA…vB), and the oldest release links to its tag page. These URLs are constructed as plain text and never requested by the tool.

  • Major / Minor / Patch buttons follow SemVer reset rules (major resets minor+patch)
  • Pre-release and build metadata are normalised away to a clean x.y.z
  • Optional [unreleased]/[x.y.z] GitHub compare links built from owner + repo
  • Compare URLs assume Git tags like v1.2.0 and are built as text, not fetched
  • The author decides the bump kind; the tool only computes the number
Privacy & Security

Privacy, Preview and Writing for Humans

Because the CHANGELOG.md is assembled in the browser, no version, date or entry text is uploaded, logged or stored, and the page works offline once cached. A live preview renders the assembled Markdown to read-only HTML locally with the marked library, alongside the raw Markdown that can be copied or downloaded as CHANGELOG.md. The page provides a start-fresh template and a worked example, and an honest note reminds authors that a changelog is for humans: entries should be short, plain-language descriptions of impact rather than raw commit messages, the semver buttons only suggest the next number, and the compare links assume conventional Git tags — adapt the result to your project.

  • No upload, logging or storage — works offline once cached
  • Live HTML preview rendered locally via the marked library
  • Copy the Markdown or download a CHANGELOG.md file
  • Start-fresh and worked-example templates included
  • Honest note: write for humans and adapt the scaffold to your project
Changelog building: in-browser (AnyTool) vs typical online changelog generators
CapabilityAnyToolTypical online generators
ProcessingRuns entirely in your browserOften server-side or AI-backed
FormatKeep a Changelog 1.1.0, six groupsVaries / loosely structured
Unreleased sectionPersistent, always emittedOften missing
VersioningSemVer Major/Minor/Patch bump buttonsManual entry
Yanked releases[YANKED] marker supportedRarely supported
Compare linksOptional GitHub compare URLsFew or none
PreviewLive Markdown + rendered HTML (local)Markdown only or none
PrivacyNever uploaded, works offlineMay transmit or log input
Cost / signupFree, no signupOften gated or ad-heavy

AnyTool assembles the CHANGELOG.md locally in the browser and uploads nothing; compare links are built as text, not fetched.