Docker Image Tags and Digests

Docker image tags are human-readable references that can be moved to different image versions, while digests identify specific image content. Tags are convenient for development and releases; digests provide content-addressable, reproducible references.

A Docker image can be referenced with a repository name and tag, such as `myapp:1.2`. The tag is a named reference maintained by the registry, so the image associated with that tag can change when another image is pushed using the same tag.

A digest is a cryptographic content identifier, commonly shown as `sha256:...`. A reference such as `myapp@sha256:abc...` points to the specific manifest identified by that digest, rather than relying on a mutable tag name.

You can use both forms together: `myapp:1.2@sha256:abc...`. In that form, the tag communicates the intended version while the digest determines the exact content Docker should use. If the tag and digest do not correspond, the digest determines the referenced content.

For deployments, pinning images by digest can make rollouts reproducible because the same digest refers to the same registry content. Tags remain useful when you deliberately want a moving reference, such as a development tag that is updated as new builds are published.

When troubleshooting a deployment, compare the image tag and resolved digest. A tag such as `latest` does not guarantee that two machines pulling it at different times receive identical image content if the registry has moved that tag.

Key points

• Tags are mutable names that can be reassigned to different image versions.
• Digests are content-addressable identifiers for a specific image manifest.
• A tag such as `latest` should not be treated as an immutable version.
• Using `repository:tag@digest` combines human-readable intent with an exact content reference.
• Digest pinning helps make deployments reproducible and auditable.

Interview questions

What is the difference between a Docker image tag and digest?

A tag is a human-readable name such as `1.2` or `latest` that points to an image reference. That reference can be changed by publishing another image under the same tag. A digest is a content-addressed identifier, typically using SHA-256, that identifies a particular image manifest. Therefore, a digest is appropriate when the deployment must refer to exact image content.

Why might a production deployment use an image digest instead of a tag?

A digest makes the image reference deterministic because it identifies specific registry content. If a tag is moved after deployment, another host pulling that tag can obtain different content. Pinning the digest reduces this source of drift and makes the deployed artifact easier to audit. Teams can still retain a version tag for readability while deploying the corresponding digest.

Can a Docker tag be considered immutable?

Not by Docker's tag semantics alone. A tag is a named reference and can be updated to point at another image. A registry or organizational publishing policy can enforce immutability for particular tags, but that is an additional control rather than an inherent property of tags. A digest provides content-addressed identity regardless of whether a tag later moves.

What does `repository:tag@sha256:...` mean?

It combines a human-readable tag with a digest in one image reference. The tag communicates the intended named version, while the digest identifies the exact manifest being referenced. This gives operators useful release information without sacrificing content-addressed specificity. The tag should not be relied on as the mechanism that guarantees the exact content.