Table of Contents
Understanding Identifiers for Images
When you work with Docker images, you rarely refer to them by a raw ID. Instead, you use human readable identifiers that tell Docker exactly which image you want. These identifiers are tags, version labels, and cryptographic digests. Although people often talk about them together, they serve different purposes and have different guarantees.
In this chapter you will learn what each of these identifiers means, how they are written, and why they matter for reliability and reproducibility.
What Is a Tag?
A tag is a label that points to a specific image version in a registry. It is part of the full image name, after a colon. For example, in the name nginx:1.25, nginx is the repository name and 1.25 is the tag. Tags are chosen by humans and can be changed at any time by whoever owns the repository.
If you do not specify a tag, Docker automatically uses the tag latest. This does not mean it is literally the newest image, only that the repository owner decided that this tag should currently point to some chosen image.
Important rule: nginx and nginx:latest are exactly the same reference. Omitting the tag is the same as explicitly using :latest.
Tags are convenient for day to day work and are easy to remember. However, they are not stable identifiers. A tag like 1.25 or latest can be moved to a different image build later. This flexibility is helpful for development but can be risky in production if you expect a tag to always mean the same bits.
Versioned Tags and Semantic Versioning
Many official images follow a versioning scheme that mirrors the underlying software. For example you may see tags like 3, 3.12, or 3.12.2 for a language runtime. These typically follow semantic versioning, often called SemVer, which uses a number format like:
$$
\text{MAJOR.MINOR.PATCH}
$$
For example, 2.7.15 has major version 2, minor version 7, and patch version 15. Image authors often provide several related tags that all point to the same image. For instance, at a given moment all of these might refer to the exact same build:
python:3, python:3.12, python:3.12.2
The maintainer may then move python:3 and python:3.12 to newer builds in the future while python:3.12.2 usually stays tied to that specific patch release.
Key idea: Versioned tags like :3.12.2 are usually more stable than broad tags like :3 or :latest, but they are still tags and can be changed by the image maintainer.
As a beginner you do not need to master semantic versioning theory, but it helps to recognize that shorter tags are usually more general. A tag with only the major version is more likely to be updated frequently. A tag with full MAJOR.MINOR.PATCH is typically more specific and changes less often.
Common Tag Patterns You Will See
Docker registries do not enforce any tag naming rules beyond some basic syntax. Still, many communities follow consistent patterns. You will commonly encounter tags that combine a software version with other properties. For example:
node:20-alpine might mean Node.js version 20 on top of the Alpine Linux base image.
node:20-bullseye might be Node.js 20 on Debian Bullseye.
node:20-alpine3.19 might be even more specific about the base image.
Some images also encode architecture or special build variants in the tag, such as -slim for a smaller base system, -bookworm for a particular Debian release, or -windowsservercore for a Windows based image. These are just naming choices. Docker itself does not interpret them. They help humans understand what kind of environment they are pulling and running.
When you choose a tag, you trade convenience for control. A short tag is easy to type and remember. A long, very specific tag describes the exact environment, which helps avoid surprises when you rebuild or redeploy.
What Are Image Digests?
An image digest is a cryptographic identifier that represents a specific, immutable image. While a tag might move and point to a different build later, a digest always refers to exactly one image and its contents. The digest is computed from the image data. If any byte in the image changes, the digest changes.
A full image reference that uses a digest looks like this:
nginx@sha256:abcd1234...
Here, sha256:abcd1234... is the digest. The registry calculates it using the SHA 256 hash function. You will usually not need to calculate or memorize digests yourself, but you will see them in commands and logs.
Crucial statement: A digest uniquely identifies one exact image. If you pull by digest, you always get the same bits, regardless of how tags might change later.
Pulling by digest is fundamental for reproducible environments and for security sensitive contexts where you must be certain that the image has not changed since you last inspected or approved it.
Tags, Versions, and Digests Working Together
A single image in a registry can have multiple tags and one digest. Conceptually, you can think of the digest as the image’s fingerprint and tags as names that people attach to it. At any time, the registry might have a mapping such as:
digest sha256:abcd1234... points to an image built on a certain date. Tags latest, 1.25, and 1.25.3 might all currently point to this very same digest.
Later, the maintainer might push a new build and update latest and 1.25 to point to a new digest, for example sha256:deadbeef..., but leave 1.25.3 pointing at the old digest. Once a digest is created, the image data behind it does not change. What can change is which tags refer to which digest.
Because of this, you can mix and match how you reference images. In casual development, you might use tags like :latest or :3.12. For strict builds, you might pin to a digest. Some teams use tags in their Dockerfiles but record the corresponding digest in documentation or lock files. Others write Dockerfiles that reference digests directly for maximum reproducibility.
Stability and Reproducibility Considerations
If you rebuild or redeploy a system later and want the environment to be identical, you must control which identifier you use. Tags are human friendly but can change beneath you. Digests are verbose and less readable but give you guarantees.
Many workflows start with a tag and then discover and record the corresponding digest. For example, you might test an image referenced as myapp:1.0.0. Once you trust it, you can pin this exact build by using its digest. If someone later pushes a different myapp:1.0.0 image, which is technically possible, your pinned digest reference will still pull the original build you tested.
Practical rule: Use clear tags during development for convenience, but rely on digests or fully specified version tags when you need exact, repeatable results.
Understanding the relationship between tags, versions, and digests is essential when you progress to topics such as registries, security, and production deployment. For now, remember that tags are labels you can see and choose, versions are a common pattern used inside tags, and digests are the unchanging identifiers that stand behind them.