{{ result.summaryTitle }}
{{ result.primary }}
{{ result.summaryLine }}
{{ badge.label }}
Use the release heading users should see in CHANGELOG.md.
ISO dates keep the generated heading clear across regions.
Choose how the release notes you paste should be parsed.
{{ semverPolicyHelp }}
Release entry is ready to paste into an existing changelog; full file adds the standard header.
{{ sourceHelp }}
{{ fileStatus || 'Drop TXT, MD, or LOG onto the textarea.' }}
Optional title context for full-file output and DOCX exports.
Paste the project repository URL when you want compare links.
Optional compare-base version for reference links.
Off omits categories with no entries.
{{ include_empty_sections ? 'Include' : 'Omit' }}
Add an empty Unreleased heading above the release entry in full-file output.
{{ include_unreleased ? 'Add' : 'Skip' }}
Leave off when repeated entries are intentional review notes.
{{ collapse_duplicates ? 'Collapse' : 'Keep' }}
Use only when the release was withdrawn after publication.
{{ yanked_release ? 'Yanked' : 'Normal' }} 
{{ result.markdown }}
# Category Change Source SemVer signal Copy
No change entries parsed yet.
{{ row.index }} {{ row.category }} {{ row.change }} {{ row.source }} {{ row.semver }}
Check Status Detail Action Copy
{{ row.check }} {{ row.status }} {{ row.detail }} {{ row.action }}
Tags: Devtools, Productivity
Export to PDF Fullscreen
Customize
Advanced
:

A changelog is a release-facing record of notable software changes. It gives users, maintainers, support teams, and auditors a compact answer to what changed, what was fixed, what might break, and what needs attention before an upgrade.

Good changelog entries separate feature additions from fixes, removals, deprecations, and security work. That separation matters because readers scan release notes for different reasons. A product owner may look for new capability, an operations team may look for upgrade risk, and a security reviewer may look for patched exposure.

Keep a Changelog gives the record a familiar Markdown shape with headings such as Added, Changed, Deprecated, Removed, Fixed, and Security. Semantic Versioning adds a second signal by linking release numbers to compatibility intent: major for incompatible changes, minor for compatible additions, and patch for compatible fixes.

A generated changelog draft still needs human review. Category names and commit markers can organize release evidence, but they cannot prove that a change was described clearly, that migration notes are complete, or that a version number matches the real public API impact.

Technical Details:

Keep a Changelog format is built around release headings and named change sections. A release heading normally carries a version and date, while an Unreleased heading holds work that has not yet been tagged. The section names help readers distinguish new behavior from maintenance fixes and risk-bearing changes.

Conventional Commits can supply the same intent from commit subjects. A header such as feat(api): add retry policy exposes a type, optional scope, and description. A bang before the colon or a BREAKING CHANGE: footer marks compatibility risk and should be treated more seriously than ordinary feature or fix wording.

Release lines flowing into changelog categories, Markdown output, and SemVer audit signals.

Transformation Core:

The generated entry follows an ordered parsing path. Lines are normalized, optional bullets are stripped, a category or commit type is detected, then the change text is placed into the standard changelog section order.

Source Pattern Parsing Behavior Output Effect
Category prefix such as added:, fixed:, or security: The prefix maps to Added, Fixed, Security, or another supported Keep a Changelog category. The cleaned change appears under that Markdown section.
Markdown heading such as ### Added The heading sets the current category for following bullet or plain-text lines. Following entries inherit the heading category until another recognized heading appears.
Conventional Commit header such as feat(ui): add filters The type maps to a category, and the optional scope is kept in brackets before the change text. The ledger records the original source type, category, change text, and SemVer signal.
Uncategorized non-empty line The line is accepted and mapped to Changed. A warning explains how many lines were defaulted so the draft can be tightened.
Duplicate category and change pair Duplicates are removed only when duplicate collapsing is enabled. The warning block and audit row report the collapsed count.

Release Signal Rules:

The SemVer signal is a review hint, not an automatic version decision. In release-note category mode, the category controls the signal. In strict Conventional Commits mode, only feat, fix, and breaking markers affect the signal.

Condition Release-Note Categories Conventional Strict Review Meaning
Breaking marker or BREAKING CHANGE: footer Major Major Confirm migration notes and public compatibility impact.
Removed entry Major Depends on commit marker Removal often needs a major-release review unless project policy says otherwise.
Added, Changed, or Deprecated entry Minor Minor only for feat Compatible additions and deprecations usually deserve release-note attention.
Fixed or Security entry Patch Patch only for fix Compatible corrections and security fixes usually fit patch release notes.
Documentation, build, CI, chore, test, style, refactor, or performance type Mapped by generated category No bump These lines may still belong in a changelog, but strict Conventional Commits does not make them version-bump signals.

Version headings accept a release version, a leading v tag style, or Unreleased. Published releases should use an ISO date in the heading. Reference compare links are emitted only when a repository URL is supplied and version links are enabled.

Everyday Use & Decision Guide:

Start with Source format set to Categorized entries when the release notes already have words like added, changed, fixed, or security at the start of each line. Use Conventional commits when the source is a list of commit subjects such as feat(exports): add markdown download or fix(parser): keep scoped commits.

Use Release entry only when you are updating an existing changelog. Use Full CHANGELOG.md when you need a starter file with the standard title, explanatory note, and optional Unreleased section. Add Project name only when that full-file heading or exported document title needs project context.

  • Keep Release date as YYYY-MM-DD for tagged releases. Set Version to Unreleased when the entry is still a holding area.
  • Choose Release-note categories when removed, deprecated, security, and changed entries should affect the SemVer signal.
  • Choose Conventional Commits strict when the SemVer signal should follow only feat, fix, !, and BREAKING CHANGE.
  • Enable Reference compare links only when Repository URL and Previous version are ready for compare links.
  • Turn on Empty sections for checklist-driven releases; leave it off when readers should see only sections that contain entries.
  • Turn on Duplicate entries only when repeated lines are accidental. Leave duplicates visible when repeats came from separate reviewers.
  • Use Yanked release only for a version that was withdrawn after publication.

A warning does not always mean the changelog is unusable. It may mean a non-category heading was skipped, one line was mapped to Changed, or a repository URL is missing for compare links. Read Release Audit before copying the final Markdown so the warning and action row are reviewed together.

A clean generated entry does not prove the release is ready. It means the pasted source was parsed into a coherent changelog structure. Compare Change Ledger with the actual release diff before publishing a tag, especially when the summary shows a Major or Minor SemVer signal.

Step-by-Step Guide:

Work from release identity to source parsing, then check the audit before using the generated Markdown.

  1. Enter Version. Use values such as 2.4.0, v2.4.0, 2.4.0-rc.1, or Unreleased. If Release Audit says the version is not full MAJOR.MINOR.PATCH syntax, fix the version before publishing.
  2. Set Release date. For a published version, the audit expects YYYY-MM-DD; for Unreleased, the date check is treated as ready.
  3. Choose Source format. Pick Categorized entries for category prefixes or Markdown headings, and Conventional commits for one commit subject per line.
  4. If Conventional commits is selected, set SemVer signal to either Release-note categories or Conventional Commits strict. The summary badge should change if the strongest signal changes.
  5. Choose Output scope. Release entry only fills Changelog Markdown with one release block; Full CHANGELOG.md adds the file heading and optional Unreleased section.
  6. Paste release lines into Release changes, drop a TXT, MD, or LOG file, or use Browse TXT. If the file is larger than 512 KB, use a smaller source or paste the relevant excerpt.
  7. Use Normalize lines when copied text has mixed line endings or trailing spaces. The source status should confirm that line endings and trailing spaces were normalized.
  8. Open Advanced for Version links, Repository URL, Previous version, empty sections, duplicate handling, or yanked release status.
  9. Read the summary box and any Changelog notes. Warnings such as uncategorized lines, ignored non-commit lines, bad dates, or missing repository URLs should be resolved or intentionally accepted.
  10. Review Change Ledger. The Category, Change, Source, and SemVer signal columns should match the release story you want readers to see.
  11. Open Release Audit before copying Changelog Markdown. The rows for version heading, release date, category coverage, source parsing, version links, and duplicate entries should show the expected status.

Interpreting Results:

Read the summary as a compact release check. The notable-change count should match the rows you expected to publish, the section count should match the categories you intended to include, and the SemVer signal should match the strongest release risk found in the parsed rows.

Changelog Markdown is the copy-ready draft. Change Ledger explains how each line was classified. Release Audit explains what should be reviewed before publishing. JSON is useful when another process needs the same structured result.

Result Cue What It Means What to Verify
Major signal A breaking marker or removed entry raised the strongest SemVer signal. Confirm migration notes, removed behavior, and version plan before tagging.
Minor signal Added, changed, deprecated, or feat evidence is the strongest signal. Check whether the planned version and release notes reflect compatible new capability or deprecation.
Patch signal Fix or security evidence is the strongest signal under the chosen policy. Confirm the change is compatible and that security wording is neither vague nor overexposed.
Review in Release Audit A field or parsing condition needs attention, such as a blank version, non-ISO date, missing repository URL, or collapsed duplicate. Use the audit row's action before copying the final Markdown.
Mapped uncategorized line(s) to Changed At least one line had no recognized category or commit shape. Add an explicit category prefix if Changed is not the right section.

A ready audit row means the draft is structurally consistent under the selected settings. It does not mean the release notes are complete, the SemVer version is correct for the real API change, or the wording is safe to publish without maintainer review.

Worked Examples:

Category-prefixed patch release. With Version set to 2.4.1, Release date set to 2026-05-06, and Source format set to Categorized entries, lines such as fixed: Preserve blank lines when copying release notes and security: Redact token values in audit exports should appear under Fixed and Security in Changelog Markdown. Change Ledger should show two rows, and the summary should report a Patch SemVer signal.

Conventional Commit feature release. A source list with feat(exports): add changelog markdown download, fix(parser): keep scoped commits in the change ledger, and docs: refresh examples should classify the feature as Added, the fix as Fixed, and the documentation row as Changed. Under Conventional Commits strict, Release Audit should recommend a Minor signal because feat outranks fix and docs has no strict SemVer bump.

Breaking release review. A line such as perf!: remove legacy changelog cache should place BREAKING: at the start of the generated change text and raise the summary to a Major SemVer signal. The Markdown can be structurally ready while the release still needs migration wording and a version-number check.

Troubleshooting an unclear paste. A pasted line like Updated the export buttons has no category prefix and no Conventional Commit type. In categorized mode, the warning block should say one uncategorized line was mapped to Changed. Rewriting the line as changed: Update export button labels removes that warning and makes the Source column easier to audit.

Compare links missing a repository URL. If Version links is set to Reference compare links but Repository URL is blank, Release Audit should show Version links as Review. Add the repository URL or switch Version links to No version links before copying the Markdown.

FAQ:

Why did my line go into Changed?

In categorized mode, a non-empty line without a recognized category prefix, Markdown category heading, or Conventional Commit shape is accepted as Changed. Add a prefix such as added:, fixed:, or security: when another section is more accurate.

Why does strict Conventional Commits ignore docs or chore for the SemVer signal?

Strict mode gives SemVer weight to feat, fix, !, and BREAKING CHANGE. Other valid types can still appear in the changelog, but they do not raise the strict bump signal unless they carry a breaking marker.

Can I generate an Unreleased entry?

Yes. Set Version to Unreleased. The generated heading becomes ## [Unreleased], and the release date audit treats the missing date as ready for an unreleased holding section.

Why did my file fail to load?

The file reader accepts TXT, MD, and LOG-style text sources up to 512 KB. Use a smaller file, paste the relevant release lines, or remove binary content before trying again.

Does the SemVer signal choose my final version?

No. The signal reports the strongest parsed release note or commit marker under the selected policy. The final version still depends on the actual public API change, project policy, and maintainer review.

Does pasted release text leave the page during parsing?

The Markdown, ledger, audit, CSV, and JSON results are produced in the page from the text you paste or load. DOCX export uses the site's document export path, so use the text and CSV outputs when release text must stay within page-generated files.

Glossary:

Changelog
A release record that lists notable changes by version or Unreleased section.
Keep a Changelog
A common changelog format using named sections such as Added, Changed, Deprecated, Removed, Fixed, and Security.
Conventional Commit
A commit header with a type, optional scope, optional breaking marker, and description.
SemVer signal
The Major, Minor, Patch, or No bump hint inferred from categories or commit markers.
Unreleased
A changelog section for changes that are recorded but not yet assigned to a released version.
Yanked release
A release that was published and later withdrawn, marked in the heading with [YANKED].
Reference compare link
A Markdown reference link that points from the previous version to the current version or from the current version to HEAD.

References: