Paste rough bullets, git log output, or Conventional Commits. One change per line.
Ready to format
Paste changelog bullets and click Format Notes// turn rough bullets into polished release notes
Turn rough changelog bullets into polished, grouped release notes by change type. Format changelogs for GitHub, npm, or product updates instantly.
Paste rough bullets, git log output, or Conventional Commits. One change per line.
Ready to format
Paste changelog bullets and click Format NotesAdd raw changelog lines, git log entries, or Conventional Commits — one item per line.
Enter the version number and release date in the options bar above the editor.
Click Format Notes, then copy the Markdown or download a .md file.
The Release Notes Formatter takes your raw, unstructured changelog bullets and automatically groups them into a clean, professional release notes document — sorted by change type: Breaking Changes, Features, Bug Fixes, Performance, Docs, and more.
It understands Conventional Commits prefixes (feat:, fix:, chore:) and also smart-detects plain English descriptions.
Conventional Commits is a standard for commit messages: type(scope): description. Types include feat, fix, chore, docs, refactor, perf, and more. This tool auto-detects these prefixes and groups lines accordingly.
No problem. The formatter uses keyword detection to categorize plain-English bullets. Lines mentioning "add", "new", or "feature" go into Features; "fix", "bug", or "resolved" go into Bug Fixes; and so on. Uncategorized items land in "Other Changes."
Yes — select the Markdown format and the output is ready to paste directly into GitHub's Release editor. The grouped headings and bullet lists render beautifully on GitHub.
All formatting is done client-side in your browser. Your changelog content is never transmitted or stored anywhere.
The formatter groups into: Breaking Changes, New Features, Bug Fixes, Performance, Documentation, Style/UI, Refactoring, Tests, Chore/Build, and Other Changes. Empty groups are hidden from the output.
Start the line with breaking:, BREAKING:, or BREAKING CHANGE:. The formatter detects these and places them at the top of the output with a warning emoji.
Yes — click the Download button to save the formatted notes as a CHANGELOG.md (Markdown format) or CHANGELOG.txt (plain text) file.
Currently the tool formats one version at a time. For multi-version changelogs, format each version separately and append them to your CHANGELOG.md file.
A Release Notes Formatter is a tool that takes unstructured, rough changelog bullets — the kind developers jot down during a sprint or pull from a git log — and transforms them into a clean, well-organized release notes document. Instead of manually sorting "fix:", "feat:", and "chore:" entries, the formatter automatically groups them by change type, capitalizes entries consistently, and produces a publish-ready Markdown or plain-text output.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and developer resources — worth checking out.
Release notes are the primary communication channel between developers and their users, stakeholders, and downstream consumers. Poorly formatted changelogs — walls of unorganized bullets, inconsistent capitalization, mixed concerns — make it hard to quickly assess what changed and how it impacts existing integrations.
Polished release notes convey professionalism and respect for your audience's time. A well-structured changelog with clear groupings (Breaking Changes first, Features next, then Fixes) lets users scan for what matters to them in seconds. This is especially important for library authors, open-source maintainers, and SaaS products publishing public changelogs.
Conventional Commits is a lightweight specification for commit message formatting that has become a de facto standard in the JavaScript ecosystem and beyond. The format is: type(optional-scope): description. Common types include:
Tools like semantic-release and standard-version use Conventional Commits to automate versioning and changelog generation. Even if you don't use those tools, following the convention makes formatting your release notes much easier — and this tool handles the grouping for you automatically.
The Release Notes Formatter uses keyword matching to categorize each bullet. Lines beginning with feat, feature, add, or new become Features. Lines starting with fix, bug, bugfix, hotfix, or resolved become Bug Fixes. chore, build, ci, deps, or upgrade entries land in Chore/Build. Plain-English bullets that don't match any pattern are placed in Other Changes, so nothing gets lost.
Breaking changes are always surfaced at the top of the output — these are the most critical for consumers to notice and they deserve prominent placement.
The Markdown format uses ## for the version heading and ### for group headings, with bullet lists for individual items. This renders natively on GitHub, GitLab, npm, PyPI, and most documentation platforms. If you're publishing to a system that doesn't support Markdown — an internal wiki, email newsletter, or legacy ticketing system — switch to Plain Text mode, which uses equals-sign and dash underlines for headings.
Good release notes are written in the imperative mood: "Add dark mode toggle," not "Added dark mode toggle" or "Adding dark mode toggle." Each entry should describe what changed and why it matters, not how it was implemented. Keep entries short — one line per change. If a change needs explanation, link to the relevant issue or pull request rather than expanding the entry. Group related sub-items under a parent entry using nested bullets sparingly.
Avoid internal jargon that external users won't understand. Phrases like "refactor AuthService to use new DI container" mean nothing to an end user — rephrase as "Improve login performance and reliability." Think about your audience: end users care about what changed for them; developers care about API changes and dependency updates.
The Keep a Changelog initiative popularized the practice of maintaining a curated, human-readable CHANGELOG.md file at the root of every project. Unlike auto-generated git logs, a maintained CHANGELOG includes only meaningful changes presented from the user's perspective. It follows the structure: newest version at top, each version with a date, and changes grouped by type.
This formatter makes it easy to generate CHANGELOG entries in that style. Format your notes, then prepend them to your existing CHANGELOG.md. Over time you build a complete, searchable history of your project's evolution — invaluable for debugging regressions, communicating with stakeholders, and onboarding new contributors.
While this tool is browser-based, the same grouping logic can be replicated in scripts. Many teams collect commit messages since the last tag using git log v1.2.0..HEAD --pretty=format:"%s", paste the output here before a release, and copy the formatted notes into their GitHub Release. For fully automated workflows, tools like semantic-release, release-please, or auto can generate changelogs from Conventional Commits with no manual step required.