Commit messages are written for the team. A changelog is written for the people who use your software. The Changelog Writer turns the first into the second, taking raw notes such as commit messages, ticket titles or a quick list and returning an entry ready for your CHANGELOG.md or release page.
It follows the Keep a Changelog convention. The entry starts with a level-2 heading for the version and the date, then groups the items under Added, Changed, Deprecated, Removed, Fixed and Security, in that order and only when a group has items. Each item becomes a short sentence that starts with a verb, duplicates are merged, internal noise such as merge commits is dropped, and breaking changes get the BREAKING prefix.
Ticket numbers stay where you wrote them, and the tool never adds a change you did not list. It belongs to the Developer tools family. For a longer explanation of a new feature, the documentation article tool is a better fit.
What you get
- A version heading in the form ## [version] - YYYY-MM-DD, with the date from your notes or a [YYYY-MM-DD] placeholder
- Items grouped under Added, Changed, Deprecated, Removed, Fixed and Security, empty groups left out
- User-facing sentences that start with a verb, with duplicates merged
- Breaking changes marked with the BREAKING prefix
What you fill in
- Version required
-
Use semantic versioning (major.minor.patch) if you can.
- Changes in this release required
-
Raw notes are fine. Add the release date if you want it shown.
How to use it, step by step
-
Open Changelog Writer
You find it in the Developer tools family. The form asks for two things, Version and Changes in this release.
-
Enter the version number
Use semantic versioning such as 2.4.0 if you can. It appears in the heading exactly as you type it.
-
Paste the changes, one per line
Commit messages, ticket titles or rough notes are all fine. Add the release date anywhere in the notes if you want it in the heading.
-
Generate, check and paste
Choose the output language, generate, then check the grouping and paste the entry at the top of your changelog.
Example, input and output
Input
- version
- 2.4.0
- changes
- release 2026-10-15 feat: export invoices to CSV (#412) fix: date picker showed wrong month in Safari (#398) Merge branch 'main' into dev chore: fix typo in comment remove legacy v1 API endpoints, breaking (#405) feat: dark mode for the settings page
Output
### Added
- Add CSV export for invoices (#412).
- Add dark mode to the settings page.
### Removed
- BREAKING Remove the legacy v1 API endpoints (#405).
### Fixed
- Show the correct month in the date picker on Safari (#398).
Illustrative example written by the editorial team to show the expected format.
Tips for better results
- Paste everything, including noisy commits. Sorting out what users care about is the tool's job.
- Write breaking in the note of any change that breaks compatibility, so it gets the BREAKING prefix.
- Put the release date in the notes in YYYY-MM-DD form to avoid a placeholder in the heading.
- Keep ticket numbers in the notes, they make each item traceable.
Who uses it, and for what
Open source maintainers
Turn the commits since the last tag into an entry for CHANGELOG.md and the release on your code host.
SaaS product teams
Write user-facing release notes from the ticket titles closed in a sprint.
Plugin and theme developers
Produce the changelog section that marketplaces and users expect with each update.
Agencies delivering to clients
Send a clear list of what changed in a delivery, written for a non-technical reader.
Limits and good practice
- It writes one entry per generation, for one version. It does not merge the full history of a project.
- It knows only the notes you paste, so a change missing from the notes is missing from the changelog.
- Group headings and the BREAKING prefix stay in English, as the convention requires, even when the items are in another language.
- Each generation uses credits from your plan, see pricing or create an account.
Frequently asked questions
What is the Keep a Changelog format?
It is a widely used convention for human-readable changelogs. Each version has a heading with the number and the date, and changes are grouped under Added, Changed, Deprecated, Removed, Fixed and Security. The latest version goes at the top. The Changelog Writer follows this structure for every entry.
Can I paste raw git commit messages?
Yes. Paste them as they are, one per line, conventional prefixes like feat or fix included. The tool rewrites each into a short user-facing sentence, merges duplicates and drops internal noise such as merge commits or typo fixes in comments, unless they matter to users.
How are breaking changes shown?
Any change your notes describe as breaking gets the BREAKING prefix, so readers cannot miss it when they upgrade. To be safe, write the word breaking next to each such change in your notes rather than relying on the tool to infer it from the code.
Can the changelog be written in another language?
Yes. Pick the output language and the items are written in it. The group headings, Added, Changed and the rest, and the BREAKING prefix stay in English because the convention requires them. Code, function names and identifiers are never translated.
Will the tool add changes I did not list?
No. It works only from the notes you paste and never invents changes, versions or dates. If the release date is not in the notes, the heading shows a [YYYY-MM-DD] placeholder for you to fill in.
Try it in your workspace
Start free, no credit card needed. When you need more, one suite grows with you, from Lite to Agency.
Sign in or create a free account, the tool opens in your workspace.