Format a Keep a Changelog entry from grouped changes

Provide a version, a release date, and lists for added, changed, fixed, or removed work. The formatter preserves the order of your descriptions, omits empty sections, and returns Markdown ready to place in a changelog. Its deterministic output is useful in release scripts, continuous delivery workflows, repository tools, and editorial checks where exactly the same input must always produce exactly the same text.

Prepare release information before formatting

Begin with a release version and date, then separate every noteworthy change into one of the four supported groups: added, changed, fixed, or removed. Added is appropriate for new functionality that users can now access. Changed describes meaningful adjustments to existing behavior, interfaces, defaults, or performance. Fixed records corrected defects, while removed identifies functionality that is no longer available. Write each list item as a complete, concise description that makes sense without internal ticket context. The formatter deliberately does not invent, summarize, or edit release notes, so the wording you provide remains the wording readers receive. Item order is also preserved within every group, allowing you to put important changes first. A group may be omitted or supplied as an empty array when the release contains no change of that type. The version cannot be empty, because an unversioned release heading would be ambiguous and unsuitable for a durable changelog. The date must likewise be supplied as meaningful text; using the familiar YYYY-MM-DD form keeps entries easy to scan and sort across regions.

Understand the generated Markdown structure

The result starts with a second-level Markdown heading containing the version in square brackets, followed by a hyphen and the supplied date. Non-empty groups then appear in the conventional order Added, Changed, Fixed, and Removed, each as a third-level heading with a bulleted list below it. This order stays stable even when the properties in an input object arrive in a different order. Empty groups do not produce headings, avoiding blank sections that distract readers and suggest missing information. Every description is trimmed at its boundaries. If a description already begins with a common Markdown bullet marker, the formatter removes that marker before adding the standard dash, which prevents accidental doubled bullets while preserving the description itself. The returned object contains the complete entry in its changelog field and ends the Markdown with a newline, making it straightforward to concatenate with other text or write through a release automation step. No current time, locale, random value, network response, or hidden state influences the output, so identical valid inputs produce identical text in the browser and through the API.

Place the formatter in a release workflow

Use the formatter after your team has decided what belongs in the release notes and before the entry is inserted into the repository changelog. A build script can collect approved descriptions from structured configuration, call the formatter, and either present the result for review or pass it to a separate file-update step. Keeping formatting separate from discovery is valuable: reviewers can assess whether every change is accurate without also debating inconsistent Markdown, while automation can rely on a predictable shape. The capability does not read commits, query issue trackers, modify files, create version links, or choose semantic versions. Those concerns remain with your existing release process, and this focused boundary makes the result easier to test. Validate the generated entry in the context of the full changelog if your project uses custom headings or link definitions. For public releases, prefer descriptions that explain user-visible impact rather than implementation details. For internal tools, retain enough precision to help operators understand migrations, compatibility changes, and removed behavior. Each request costs $0.002 through the API, while the same deterministic logic supports the browser experience.