---
title: What is a changelog? A plain definition, with examples
description: A changelog is a dated record of what changed in a product. What goes in one, who reads it, how it differs from release notes, and what a good entry looks like.
canonical: https://relnotely.com/blog/what-is-a-changelog
published: 2026-09-22
updated: 2026-09-22
---

# What is a changelog?

A changelog is a dated, public record of what changed in a product, newest first. Here is what belongs in one, who actually reads it, and the difference between the file developers keep and the page customers see.

A **changelog** is a dated record of what changed in a product, newest first. Each entry says what changed and when, so that anyone who uses the product can catch up on what is new, what got better and what was fixed.

The word covers two different documents, and most confusion about changelogs comes from mixing them up:

- **A `CHANGELOG.md` file** in a code repository, written for developers, ordered by version number.
- **A public changelog page**, written for customers, ordered by date, usually at an address like `yourcompany.com/changelog`.

## What an entry looks like

A good entry has four parts, and only the first three are required:

1. **A date.**
2. **A title that says what changed**, as a sentence: "Export any report to CSV", not "v2.4.1" and not "Exports".
3. **A sentence or two on what it means for the reader.**
4. A screenshot, when the change is something you can see.

For example:

> **Search now matches what you can see** · Improved · 19 September 2026
>
> Searching your changelog used to match the formatting behind the text as well as the text. It now matches only the words a reader can see, so a search for part of a link's address no longer turns up entries that do not visibly contain it.

## The three kinds of change

Almost everything a customer cares about is one of three things:

| Kind | Means |
| --- | --- |
| New | Something that did not exist before |
| Improved | Something that existed and now works better |
| Fixed | Something that was broken, in a way a customer could have noticed |

Developer changelogs often use six — Added, Changed, Deprecated, Removed, Fixed, Security — from the [Keep a Changelog](https://keepachangelog.com) convention. Those suit a file read by people upgrading a dependency. Three is enough for a page read by customers.

## Who reads it

- **Customers**, to see whether the thing they asked for shipped.
- **People deciding whether to buy**, who look at the dates before they read a word. A changelog updated last week says the product is alive; one last updated a year ago says something else.
- **Your own team.** Support links to it, sales quotes it, and new hires read it to learn what the product does.
- **Search engines and AI assistants**, which read it to answer "does this product do X yet?"

## What does not belong in one

- Refactors, dependency upgrades and other work with no visible effect. Those go in the repository's file, if anywhere.
- Version numbers as titles, unless your customers install versions.
- Anything you cannot describe plainly. If half an entry has to be vague, it is not ready to announce.

## Where a changelog lives

A public changelog does most good in three places at once: on a page of its own, so it can be linked and found; inside the product, as a small "what's new" widget, so returning users see what changed; and in email, for the people who asked to be told.

[How to write release notes people actually read](/blog/how-to-write-release-notes) covers the writing itself. If you already have a `CHANGELOG.md`, the free [CHANGELOG.md Validator](/tools/changelog-md-validator) checks its format, and the [Changelog Grader](/tools/changelog-grader) reports on a public page.

## Questions

**What is a changelog, in one sentence?**

A changelog is a dated list of the changes made to a product, newest first, written so that someone who uses the product can see what is new, what got better and what was fixed.

**What should a changelog include?**

Each entry needs a date, a title that says what changed, and a sentence or two on what it means for the reader. Group entries as new, improved or fixed. Leave out internal work nobody outside the team can see.

**Who reads a changelog?**

Existing customers checking what changed, prospective customers checking the product is alive, your own support and sales teams looking for something to link to, and increasingly search engines and AI assistants answering questions about your product.

**How often should a changelog be updated?**

Whenever something ships that a user could notice. For most small software teams that is weekly. A steady rhythm matters more than volume.

**Is a changelog the same as release notes?**

Nearly. Release notes describe one release; a changelog is the running record of all of them. In practice a public changelog is a list of release notes.

---

Published by Relnotely at https://relnotely.com/blog/what-is-a-changelog