Awesome question—these SHA256 identifiers pop up all the time when working with Docker images and private registries, and it’s super easy to mix them up. Let’s break down each one clearly, so you know exactly what each is doing and how they differ:

Manifest SHA256 #

Think of the manifest as the "blueprint" for your Docker image. It’s a JSON file that contains every bit of metadata about the image: which layers (blobs) it’s made of, the image configuration, tags, supported architectures, and more. The SHA256 here is a hash of the entire manifest file content.

This identifier uniquely marks a specific version of an image. For example, if you have two images tagged my-app:v1 and my-app:latest, if their manifest SHA256 matches, they’re identical under the hood. When you run docker pull, Docker first fetches this manifest to know exactly which blobs it needs to download next.

ETag #

ETag is an HTTP standard header, not specific to Docker—though registries use it heavily for cache validation. Its value is often a SHA256 hash, but it’s not guaranteed (some registries might use other hashing algorithms or even arbitrary strings).

The main job of an ETag is to let Docker (or any client) check if a resource (like a manifest or blob) has changed since the last request. If you send a request with the ETag you previously received, the registry will send back a 304 "Not Modified" response if nothing’s changed—saving you from re-downloading the same content. Unlike the other identifiers here, ETag is a registry-specific marker for caching, not a universal content hash.

Docker-Content-Digest #

This is a Docker-specific HTTP response header, and it’s all about content integrity. The value is a SHA256 hash calculated directly from the content of the resource (either a manifest or a blob).

The key thing here is that this digest is universal: no matter which registry you pull the same content from, the Docker-Content-Digest will be identical. Docker uses this to verify that the content it downloaded hasn’t been tampered with—if the local hash of the content doesn’t match the digest from the registry, it’ll throw an error. You’ll often see this digest used in commands like docker pull <image>@sha256:<digest> to pull an exact, immutable version of an image.

Blob SHA256 #

Blobs are the actual "layer files" that make up a Docker image. Each blob represents a set of changes to the filesystem (like adding a new directory or installing a package). The SHA256 here is the hash of the blob’s content.

This identifier lets Docker reuse layers across images—if two images share the same base layer, they’ll reference the same blob SHA256, so Docker only needs to download that layer once. You can see these hashes if you run docker inspect <image> and look at the RootFS.Layers field, which lists all the blob digests for the image’s layers.

Quick Cheat Sheet to Tell Them Apart #

• Manifest SHA256: Uniquely identifies the entire image’s blueprint (all layers + metadata)
• ETag: Registry-specific cache marker, used to avoid re-downloading unchanged resources
• Docker-Content-Digest: Universal content hash, verifies integrity for both manifests and blobs
• Blob SHA256: Identifies a single filesystem layer of an image, enables layer reuse

内容的提问来源于stack exchange，提问作者Alison