liminfoChangelog Generator
Free web tool: Changelog Generator
About Changelog Generator
The Changelog Generator converts Conventional Commit messages into a structured, human-readable Markdown changelog following the Keep a Changelog format. Paste your commit messages one per line, set the version number, and the tool groups and labels them by type — feat becomes Added, fix becomes Fixed, refactor and style become Changed, perf becomes Performance, docs becomes Documentation, test becomes Testing, chore becomes Maintenance, ci becomes CI/CD, and build becomes Build.
Software teams use changelogs to communicate what changed between releases to users, stakeholders, and other developers. Writing them by hand from a git log is tedious and error-prone. This tool automates the grouping and formatting step: it parses each line against the Conventional Commits specification pattern (type(scope): description), extracts scope and description, and produces a neatly ordered Markdown document with the current date and version stamp.
The output follows the Keep a Changelog ordering convention — Added, Changed, Fixed, Performance, Documentation, Testing, CI/CD, Build, Maintenance — so sections are always in a predictable, reader-friendly sequence. Lines that do not match the conventional commit pattern are placed in an Other section rather than being silently dropped. The generated Markdown can be copied and pasted directly into a CHANGELOG.md file or a GitHub release note.
Key Features
- Parses Conventional Commits format: type(scope): description
- Groups commits into sections: Added, Fixed, Changed, Performance, Documentation, Testing, CI/CD, Build, Maintenance
- Extracts and bolds optional scope for quick scanning (e.g., auth, api, ui)
- Adds current date automatically in ISO 8601 format (YYYY-MM-DD)
- Configurable version number field for any semver string
- Non-conventional lines placed in Other section — nothing is lost
- One-click copy of the complete Markdown changelog output
- 100% client-side — paste sensitive commit messages without any upload
Frequently Asked Questions
What is the Conventional Commits specification?
Conventional Commits is a lightweight convention for writing commit messages in a structured format: type(scope): description. The type describes the kind of change (feat for a new feature, fix for a bug fix, chore for maintenance, etc.), the optional scope names the affected area of the codebase, and the description summarises the change. Tools like semantic-release and this changelog generator parse these structured messages automatically.
What commit types does the generator recognise?
The generator recognises: feat (Added), fix (Fixed), docs (Documentation), refactor (Changed), perf (Performance), test (Testing), chore (Maintenance), style (Changed), ci (CI/CD), and build (Build). Commits with unrecognised types are placed in the Other section.
How do I include a scope in my commit message?
Write the scope in parentheses after the type and before the colon: feat(auth): add OAuth2 login. The generator extracts the scope and displays it in bold at the start of the changelog entry — auth: add OAuth2 login — making it easy to filter entries by subsystem at a glance.
What happens to commits that do not follow the convention?
Lines that do not match the type(scope): description pattern are placed in the Other section of the changelog with their full text. This ensures no commit message is silently dropped, even if it was written before the team adopted Conventional Commits.
What is the Keep a Changelog format?
Keep a Changelog is a widely adopted convention for structuring changelog files at keepachangelog.com. It specifies a standardised section ordering (Added, Changed, Deprecated, Removed, Fixed, Security) and encourages human-readable language rather than raw git log output. This tool follows the same section-based structure, adapted to the Conventional Commits type vocabulary.
Can I use this with git log output directly?
Yes. Run git log --oneline --no-merges and pipe or copy the output. The generator will attempt to parse each line. If your commit messages follow Conventional Commits format, they will be grouped correctly. Lines that start with a git short hash will be placed in the Other section since the hash prefix does not match the type pattern.
Does the tool support breaking changes (BREAKING CHANGE)?
The current version groups commits by their type prefix and does not specifically parse BREAKING CHANGE footer tokens or the ! suffix used in Conventional Commits for breaking changes. Breaking changes marked as feat!: or with a BREAKING CHANGE footer will appear in the Added or Other section depending on their type.
Can I paste the output directly into CHANGELOG.md?
Yes. The output is standard Markdown with ## for the version header and ### for section headers, matching the Keep a Changelog format. You can copy the output and prepend it to the top of your CHANGELOG.md file above previous entries for a clean, reverse-chronological changelog.