19.1.2.3 Images Tag Column

The images tag column shows the version or variant identifier portion of an image reference, and reading it correctly requires understanding that an omitted tag implicitly means latest, that the listing's default ordering is not chronological, and that local tag reassignment is never actually prevented or enforced, regardless of any naming convention suggesting a tag should be treated as fixed.

Omitted tag implies latest

Any reference to an image without an explicit tag, in a docker run, docker pull, or docker build -t command, is treated as referring to latest implicitly:

docker pull my-api
docker images my-api

REPOSITORY   TAG       IMAGE ID
my-api       latest    8a1f3c9b2e7d

This implicit behavior is precisely why an apparently tag-free reference still shows a concrete tag value in the listing, since docker images always displays the actual, resolved tag, even when the original command that created or pulled it never explicitly typed latest itself.

Default ordering is not chronological

The default docker images output order is not guaranteed to reflect creation time, which is a common, mistaken assumption; sorting explicitly by creation time, if that ordering is actually needed, requires an explicit format and an external sort:

docker images --format "{{.CreatedAt}}\t{{.Repository}}:{{.Tag}}" | sort -r

Relying on the default, unsorted order to identify "the most recently built image" is unreliable; explicitly sorting by the creation timestamp field, as shown here, is the only way to genuinely guarantee that ordering rather than assuming the default listing happens to already reflect it.

Local tag reassignment is never actually prevented

Nothing in docker tag or docker build -t prevents reassigning an already-used tag to entirely different content locally, regardless of whether that tag's naming convention, a specific version number, for instance, might suggest it should be treated as fixed and immutable:

docker build -t my-api:1.4.2 .
docker build -t my-api:1.4.2 .

Running this build twice in a row, with the source having changed in between, silently reassigns the 1.4.2 tag to the second build's content, with the first build's content becoming dangling rather than remaining accessible under that tag; this is the same underlying mutability concern covered in dedicated tag-pinning content, visible directly and concretely here in how the local image listing behaves.

The tag column does not show digest information

The tag column itself never shows any portion of an image's content digest; that information requires the separate --digests flag covered in dedicated CLI command content, which adds an entirely separate column rather than being incorporated into the tag column's own display:

docker images --digests my-api

REPOSITORY   TAG       DIGEST
my-api       1.4.2     sha256:3f29a8c1...

Confusing the tag value itself with any notion of content verification is a meaningful mistake, since the tag is purely a human-assigned label with no inherent connection to or guarantee about the specific content it currently happens to reference.

Filtering by semantic version tag patterns

The reference filter's wildcard support, covered for the repository column generally, applies equally to matching specific tag patterns, useful for finding every image matching a particular version range or naming convention:

docker images --filter "reference=my-api:1.4.*"
docker images --filter "reference=my-api:*-rc.*"

The second example specifically isolates every release-candidate-tagged image, useful for a periodic review of pre-release builds that might be worth cleaning up once their corresponding stable release has actually shipped and the candidates are no longer needed.

Common mistakes

• Assuming a tag-free image reference has no tag at all, rather than recognizing it implicitly resolves to latest.
• Relying on the default docker images listing order to identify the most recently built image, rather than explicitly sorting by the creation timestamp field.
• Assuming a specific, version-numbered tag is locally protected from reassignment simply because its naming convention suggests it should be fixed, when nothing actually enforces this locally.
• Confusing the tag column with any form of content verification, when a tag is purely a label with no inherent guarantee about the specific content it currently references.
• Not using the reference filter's wildcard pattern matching to isolate tags following a specific naming convention, scanning an unfiltered list manually instead.

The images tag column displays the resolved, explicit tag value even when a command never typed it explicitly, defaults to an unsorted, non-chronological listing order unless explicitly sorted otherwise, and never actually prevents local tag reassignment regardless of naming convention, none of which the tag column's display alone makes obvious without understanding these specific behaviors directly.