Skip to content
Markdown Viewer

Changelog & Release Notes

Audit your CHANGELOG.md and format release notes — Keep-a-Changelog ready

Lint a CHANGELOG.md against semver and Keep-a-Changelog conventions, or normalize a messy release draft into the canonical Added / Changed / Fixed sections. Includes a starter template, runs entirely in your browser.

Our project changelogDiff two changelogsPick release emoji

Hints (1)

Found 2 semver-ish section headers — verify ordering is newest-first.

How to use the changelog and release notes helper

Audit a CHANGELOG.md

  1. Open your existing CHANGELOG.md or paste its contents.
  2. The hints panel reports missing-but-recommended structure: a # Changelog title, an ## [Unreleased] working section, semver-shaped version headers like ## [1.2.0], and at least one ## section.
  3. Need a clean slate? Click Insert Keep-a-Changelog starter to drop in a battle-tested template you can edit.

Normalize release notes

  1. Switch to Release notes formatter.
  2. Paste a draft — often written in mixed case, with headings like ## what's new and ### added.
  3. The tool rewrites your H2 / H3 headings to the canonical Keep-a-Changelog sections (Added, Changed, Deprecated, Removed, Fixed, Security). Code blocks and prose are untouched.
  4. Copy the normalized output into your GitHub release, Slack channel, or roadmap doc.

The six Keep-a-Changelog sections (and when to use them)

SectionUse for
AddedNew features visible to users.
ChangedBehavior changes to existing features.
DeprecatedFeatures that still work but are scheduled for removal.
RemovedFeatures that have been removed in this release.
FixedBug fixes.
SecuritySecurity fixes — both CVEs and silent hardening.

Sticking to these six buckets makes a changelog easy to scan, easy to diff between versions, and easy for downstream consumers (release notes bots, package managers, support teams) to parse mechanically.

Anatomy of a great release entry

A solid release entry looks like:

## [1.4.0] — 2026-04-21

### Added
- Real-time collaboration cursors in the editor.

### Changed
- Default theme is now light. Use the toggle in the toolbar to switch.

### Fixed
- Crash when exporting PDFs with embedded math (#812).

### Security
- Bumped `marked` to 12.1.2 (CVE-2024-XXXXX).

Notes that pay off later:

  • Include a date. Knowing exactly when a release shipped helps support and bisection.
  • Link to issues / PRs. Future readers don't have to spelunk git for context.
  • One line per item. Helps changelog parsers and humans scan quickly.
  • Highlight breaking changes. Either a dedicated subsection or bold "(breaking)" suffixes.

Where this helper fits in a release workflow

  1. During the release branch: keep an ## [Unreleased] section growing. The audit tab catches when you forget it.
  2. At release time: rename Unreleased to the version + date, run the formatter to normalize sections, and copy into your GitHub release body.
  3. After release: run a Markdown diff of the two changelog versions to confirm nothing important got cut.

Companion tools

Privacy & data

Both tabs run client-side. Your changelog, release notes, and any embedded code never leave the browser tab.

Frequently asked questions

What is Keep a Changelog?
Keep a Changelog is a widely adopted convention for project changelogs. It recommends a single Markdown file at the repo root with one section per release, dated, in newest-first order, broken down by Added / Changed / Deprecated / Removed / Fixed / Security. This tool checks your file against those conventions.
What does the 'Changelog hints' tab check?
It looks for a top-level `# Changelog` heading, an `## [Unreleased]` section, semver-shaped release headers (`## [1.2.0]`), and at least one `##` section. Each missing or non-standard pattern surfaces as a hint with severity (info or warning). Nothing is mutated — you make the edits.
How does the release notes formatter work?
Paste a draft of release notes (often pasted from internal docs or generated by an LLM). The formatter rewrites any `## what's new`, `### added`, or `### fixed` style headings to the canonical Keep-a-Changelog casing (Added, Changed, Deprecated, Removed, Fixed, Security). Fenced code blocks are preserved untouched.
Does it generate a changelog from git commits?
No — by design. Commit-based generators (like `conventional-changelog` or `git-cliff`) are great when you control commit messages, but they don't fit teams that write release notes by hand. This tool is for hand-curated changelogs and the post-AI workflow where a teammate drafts notes and you normalize them.
Will it touch fenced code blocks?
No. The normalizer detects ``` fences and leaves their contents untouched. That keeps embedded shell commands, JSON snippets, or migration code intact while only the headings around them are normalized.
Is my changelog uploaded anywhere?
No. Both the audit and the formatter run entirely in your browser. We don't upload, log, or train on the file contents — safe for proprietary product roadmaps.