19.1.2.4 Images ID Column

The images ID column shows a truncated identifier derived from the image's configuration, distinct from both its repository name and its registry-facing content digest, and understanding precisely what this value represents, how it relates to but differs from a digest, and how to use it safely as a short reference clarifies behavior that is easy to conflate with the other, similarly hash-like values Docker displays.

What the image ID actually represents

The image ID is derived from the image's configuration object, the JSON document describing its layers, environment, entrypoint, and other metadata, not from the manifest digest a registry would actually use to identify the same image:

docker images --no-trunc

REPOSITORY   TAG       IMAGE ID
my-api       1.4.2     sha256:8a1f3c9b2e7d4b6f9c1a3d5e7f9b1d3f5e7a9c1b3d5f7e9a1c3b5d7f9a1c3b5d

docker images --digests

REPOSITORY   TAG       DIGEST
my-api       1.4.2     sha256:3f29a8c1d8e2b4f6a9c7d5e8b1f3a6c9d2e5f8b1a4c7d0e3f6a9c2d5e8b1f4a7

These two values, the image ID and the digest, are different hashes of different underlying content, the configuration object versus the full manifest, and conflating the two, assuming they should match or represent the same identity, is a common source of confusion when comparing local image identifiers against what a registry reports for the same image.

Why the same image ID can appear under different tags

Because the image ID is derived from the image's own content rather than from any tag or name applied to it, the identical image ID appearing under multiple, differently named tags confirms those tags genuinely reference the exact same underlying content, which is the most reliable way to verify two differently-tagged references actually point at identical content:

docker images

REPOSITORY   TAG       IMAGE ID
my-api       1.4.2     8a1f3c9b2e7d
my-api       stable    8a1f3c9b2e7d

Both tags here sharing this identical ID is the direct, conclusive confirmation that 1.4.2 and stable currently reference exactly the same image, regardless of how differently those two tag names might otherwise suggest a meaningful version difference.

Using a short ID safely in commands

Most commands accept a sufficiently unique prefix of the full ID rather than requiring the complete value, which is generally convenient but worth confirming for genuine uniqueness on a host with many images sharing a similar prefix:

docker run 8a1f3c9b2e7d

Unable to find image '8a1':
multiple images found with ambiguous prefix

On a host with an unusually large number of images, a short prefix occasionally fails to uniquely identify a single image, in which case providing more of the full ID, or using --no-trunc to retrieve and use the complete value directly, resolves the ambiguity.

Image ID stability versus a registry digest

An image ID is computed locally and remains stable as long as the underlying configuration does not change, but it should not be assumed to be globally, universally identical to whatever a remote registry independently computes as that same image's manifest digest, since the two are derived from genuinely different source data even though they both ultimately derive from the same underlying image:

docker inspect my-api:1.4.2 --format '{{.Id}}'
docker inspect my-api:1.4.2 --format '{{index .RepoDigests 0}}'

For any scenario genuinely requiring cross-system identity verification, comparing against a remote registry's own record, for instance, the digest is the correct value to use; the image ID is the correct value for local, same-daemon comparison and reference purposes specifically.

Comparing image IDs to confirm a rebuild produced identical content

After applying a change believed not to affect a build's actual output, comparing the resulting image ID against the previous build's ID directly confirms whether the change genuinely had no effect on the final content, which is a useful, concrete verification technique distinct from assuming based on the Dockerfile's apparent logic alone:

docker build -t my-api:test1 .
docker build -t my-api:test2 .
docker inspect my-api:test1 --format '{{.Id}}'
docker inspect my-api:test2 --format '{{.Id}}'

Identical IDs here confirm the two builds genuinely produced byte-for-byte equivalent content; differing IDs, despite an expectation of equivalence, indicate something about the build is not as deterministic or unaffected by the change as assumed.

Common mistakes

• Conflating the local image ID with a registry-facing content digest, assuming the two should match when they are derived from genuinely different underlying data.
• Assuming a short ID prefix is always sufficient, without accounting for the rare but real possibility of ambiguity on a host with a particularly large number of images.
• Not using shared image IDs across differently named tags as the direct, conclusive way to confirm those tags genuinely reference identical content.
• Using the image ID where a genuine, cross-system digest comparison was actually needed, such as verifying content against a remote registry's own independently computed record.
• Not comparing image IDs directly when verifying whether a build change genuinely had no effect on the final output, relying on assumption rather than concrete confirmation.

The images ID column represents a locally derived identifier tied to an image's configuration content, distinct from but related to the registry-facing digest, and using it correctly, for local comparison and short-reference convenience specifically, rather than as a substitute for genuine cross-system digest verification, avoids a common and easy-to-make category of confusion between these similarly hash-like but fundamentally different values.