All maker tools

Changelog and release notes formatter

Turn a pile of raw update lines into a tidy changelog. Paste one change per line, add a version and a date if you have them, and get grouped Markdown, plain text and a short what is new post. It is free, needs no account and runs in your browser.

A changelog is for people who use your product, so it helps when changes are grouped by what they mean to a reader. The tool sorts lines with simple rules and lets you correct every decision. It does not rewrite your wording.

Format your changelog

Free, no login, and processed in your browser. Categories are assigned by fixed keyword rules, not by AI. Nothing you type is sent anywhere or saved, and it is gone when you reload.

Want to see how it works? Start from a fictional set of update lines.

One change per line. Blank lines, leading bullets and numbering are ignored. 0 of 200 lines used.

Free text such as 1.4.0. Square brackets are removed. Leave it empty for an Unreleased header.

Written as YYYY-MM-DD. It is only used together with a version.

Your changelog will appear herePaste one change per line above. The grouped Markdown, plain text and a short post are built as you type.

How to use the changelog formatter

  1. Paste your raw change lines, one per line. Leading bullets such as a hyphen, an asterisk or a plus sign, and simple numbering, are removed for you. Blank lines are ignored and exact repeats are dropped.
  2. Optionally enter a version such as 1.4.0 and a release date. With no version the header says Unreleased, because that heading is meant for work that has not shipped yet.
  3. Read the category shown for each line. The fixed rules guess from the first word, so a line starting with Fix goes to Fixed. Use the select next to any line to correct it.
  4. Copy the Markdown for your changelog file, the plain text for a release page or the short post for a community update or newsletter. Read each one once before you publish.

Example with made up lines

This is a fictional product, so none of it describes a real release. Ten lines go in, including one repeat and one line that starts with a number. Nine remain after the repeat is removed. The rules place eight of them, and the line about onboarding emails matched nothing, so it was set to Changed by hand.

## [2.3.0] - 2026-10-14

### Added

- Add dark mode to the dashboard
- Added CSV export for reports

### Changed

- Improve search speed on large workspaces
- Onboarding emails now arrive faster

### Deprecated

- Deprecate the old API token format

### Removed

- Remove the legacy v1 import endpoint

### Fixed

- Fix crash when a project name is empty
- Fixed typo on the billing page

### Security

- Close a vulnerability in the file upload preview

Practical tips for release notes

Keep a Changelog suggests listing the newest version first, showing the release date of each version and keeping an Unreleased section at the top for upcoming changes. When you ship, you move those entries into a new version section. Pasting your lines without a version gives you an Unreleased block you can paste there.

Write each line for a reader, not for the person who made the change. Name what happened to the product, such as a new export option, instead of an internal ticket or a commit hash. The rules read the first word, so starting lines with a verb like Add, Fix or Remove makes the guesses more accurate.

Security entries deserve care. Say what was fixed in general terms and avoid details that help someone attack users who have not updated yet. Lines that mention a CVE number or the word vulnerability go to Security automatically, but you decide the final wording.

The short post is a starting point for a newsletter or a community post. It states the version, counts the entries and lists the first seven, and it makes no claims beyond your own lines. Add context in your own voice before sending, and see the launch announcement generator or the launch email builder for longer formats. Tag links to your release page with the UTM link builder so you can tell where visits came from.

The text you paste is kept as you typed it and is shown as plain text, never run as code. The rules read English words only, and nothing is saved, so copy your results before leaving. The product launch checklist covers the rest of a release.

Frequently asked questions

Does this tool use AI to choose categories?

No. Categories come from a fixed list of keyword rules that look at the first word of each line, plus CVE numbers or the word vulnerability anywhere in a line. The same input always gives the same result, and you can change any category yourself.

Which categories and format does it follow?

It follows the Keep a Changelog 1.1.0 convention from keepachangelog.com. The change types are Added, Changed, Deprecated, Removed, Fixed and Security. Release headers show the version and an ISO date such as 2026-10-14.

What happens to a line that matches no rule?

It is marked Uncategorised so you notice it. That label is not part of Keep a Changelog, so choose a real category for the line before you publish. Lines in other languages also land there, because the rules read English words.

Is my text uploaded or stored?

No. The page works entirely in your browser, makes no requests with your text and stores nothing. Reloading or leaving the page clears everything, so copy your results first.

How are special characters and long lists handled?

Your wording is kept as typed. Characters that would start a heading, quote, code block or HTML block at the start of a line get a backslash so the list stays intact. Up to 200 lines are accepted, and lines over 500 characters are cut with a notice.

Ready to share your product?

After a big update it is worth showing it to people, so add or refresh your product on RadarMakers and let them see what changed.

RadarMakers is a free directory for indie projects and SaaS. Prepare a clear tagline, explain who your product helps and include real screenshots when you submit.

Submit your product