Release Note Drafter for Developers

Turn messy changelogs into notes people actually read.

Paste your commits, issues, or change list. Tag each item. Pick a tone. Get clean, user-facing release notes in seconds. No account needed. Everything runs in your browser.

Open Workspace See Examples

Workspace

Your project auto-saves in the browser. Nothing leaves your device.

Quick-tag selected lines as:

Paste your changes above to get started.

Preview

Your release notes will appear here.

Example Outputs

See what ReleaseCraft produces for different project types.

SaaS Dashboard v3.1

## What's New
- Added CSV export for all report tables
- New widget: weekly active users chart

## Fixes
- Fixed incorrect totals when filtering by date range
- Resolved intermittent timeout on large exports

## Breaking Changes
- The /v1/reports endpoint now requires a `format` parameter

Open Source CLI Tool v1.5

## Features
- Added `--json` flag for machine-readable output
- New `init` command scaffolds a config file

## Bug Fixes
- Fixed crash when config file is empty
- Corrected exit code on validation errors

## Deprecations
- The `--verbose` flag is deprecated. Use `--log-level debug`.

Mobile App v4.0

🎉 Version 4.0 is here!

New in this release:
- Completely redesigned home screen
- Offline mode for saved articles
- Push notifications for replies

We also fixed:
- App no longer freezes on slow connections
- Images load correctly in dark mode

Note: This update requires iOS 16+ or Android 12+.

How to Write Better Release Notes

Start with what changed for the user

Users don't care that you refactored the auth middleware. They care that login is now faster. Write from the user's perspective. If a change has no visible effect, you can skip it or group it under "Internal improvements."

Group by impact, not by file

Don't list changes by module or file path. Group them by what the user experiences: new features, fixes, and things that might break their setup. This is the single biggest improvement most teams can make.

Call out breaking changes early

If something requires the user to change their code, config, or workflow, put it at the top and explain what to do. A breaking change buried at the bottom of a list will cause support tickets.

Keep it short

Three to seven bullet points per category is the sweet spot. If you have 30 items, pick the ones that matter most. You can link to a full changelog for the complete list.

Common mistakes

  • Copying raw git log output with hashes and merge commits
  • Using internal ticket numbers like "PROJ-1234" with no context
  • Writing "various bug fixes and improvements" with no detail
  • Forgetting to mention security fixes that users should know about
  • Publishing notes days after the release, when the moment has passed

When to publish

Write your notes before you ship, not after. Have them ready when you tag the release. If you're doing continuous deployment, batch changes weekly or biweekly so users aren't overwhelmed.

Questions

Where does my data go?

Nowhere. Everything runs in your browser. Project profiles are saved to localStorage on your device. No data is sent to any server.

Can I use this for open-source projects?

Yes. It works well for any project that publishes versioned releases. The presets include an open-source template.

How do I share my release notes with my team?

Use the Share Link button to encode your current project into a URL. Send that link to a teammate and they'll see the same input and settings. You can also download the notes as a Markdown file.

What if my changelog has 50+ items?

The workspace handles large lists, but for 50+ items consider splitting into sections or focusing on the most user-visible changes. Not every commit needs a release note line.

Can I customize the output format?

Yes. Choose between Markdown, plain text, or HTML output. You can also toggle whether to include category headers, version numbers, and dates.