Turn release notes into a changelog people read
Changelog formatter
Release notes usually start as commit lines and half-finished bullets. Paste them here and the formatter splits them into releases, sorts every line into Added, Changed, Deprecated, Removed, Fixed or Security, and writes a changelog in the Keep a Changelog layout. You can change the category of any line, then copy a three-bullet post sized for X and a longer one for Threads, plus a JSON feed item.
Everything runs in this page. Your notes are not sent anywhere or stored. Categories are a keyword guess that you are expected to review, and the formatter never rewrites the meaning of a line.
Paste git log lines, bullets or a Markdown draft to begin.
How to use it
- Paste your release notes. Git log lines, plain bullets or an existing Markdown draft all work. Version headers such as v1.2.3, 1.2.3 or a date such as 2026-10-10 start a new release.
- Check the categories. Each line gets a category from its leading verb, a commit prefix such as feat: or fix:, or a section header you pasted. Use the menu beside a line to override the guess.
- Fix any warnings. Versions that are not valid Semantic Versioning, dates that do not exist and releases without a date are listed above the entries.
- Copy the outputs. Copy the changelog Markdown, the X or Threads post for the release you pick, and the JSON feed item.
How lines are sorted, and what to check
The layout follows Keep a Changelog 1.1.0 (keepachangelog.com/en/1.1.0): an Unreleased section at the top, one heading per version in the form [version] - YYYY-MM-DD, and the six change types in this order: Added, Changed, Deprecated, Removed, Fixed, Security. The guide asks for the latest version first. The formatter keeps releases in the order you pasted them, so paste newest first. Dates use the ISO 8601 year-month-day form the guide recommends, and each is checked against the calendar.
Version numbers are validated with the regular expression published at semver.org for Semantic Versioning 2.0.0. A value such as 1.2 or 01.2.3 is flagged, because it is not valid. Classification works in this order: a section header you pasted, then a commit prefix (feat, fix, chore, docs and similar), then the first word of the line (add, fix, remove, deprecate, update and similar), then keywords anywhere in the line, and finally Changed as the default. A line mentioning a vulnerability, a CVE or XSS is always filed under Security.
The guide itself warns that raw commit logs make poor changelogs because they hold noise and obscure titles. The formatter drops merge commits and strips hashes and pull request numbers, but it cannot judge which changes matter to your users. Read the result and delete or reword anything that only makes sense to the team. The JSON feed item follows the item fields of JSON Feed 1.1 (jsonfeed.org/version/1.1): id, title, content_text, date_published and tags.
Questions
Which format does the changelog use?
Keep a Changelog 1.1.0. That means an Unreleased section, one heading per version with an ISO date, and the change types Added, Changed, Deprecated, Removed, Fixed and Security.
How does it decide whether a line is Added or Fixed?
It checks a section header you pasted, then a commit prefix such as feat: or fix:, then the first word of the line, then keywords. It is a guess, so every line has a menu to change it.
What counts as a valid version?
A version that matches the Semantic Versioning 2.0.0 pattern: three numbers separated by dots, with an optional pre-release or build part, and no leading zeros. Values such as 1.2 are flagged with a suggested fix.
Why are my social posts shorter than my notes?
The X post holds three bullets and a one-line opener in 280 characters. The Threads version allows 500. Long lines are shortened with an ellipsis, security items come first, then additions and fixes.
Does it work with commit messages from any tool?
It reads plain text lines, so output from git log with the oneline format works. It removes leading hashes, conventional commit prefixes and trailing pull request numbers, and it skips merge commits.
Is my text stored or sent anywhere?
No. Parsing and formatting are plain JavaScript in this page and nothing leaves your browser.