19.1.2.2 Images Repository Column

The images repository column in docker images output represents the name portion of an image reference, distinct from its tag, and correctly reading this column, including recognizing what <none> actually signifies and understanding that the identical underlying image can legitimately appear multiple times under different repository names, clarifies output that is otherwise easy to misread at a glance.

What the repository column actually represents

The repository column shows the name portion of a full image reference, everything before the colon separating it from the tag, which can range from a bare, simple name to a fully qualified path including a registry hostname and namespace:

docker images

REPOSITORY                          TAG       IMAGE ID
my-api                              1.4.2     8a1f3c9b2e7d
registry.example.com/myorg/my-api   1.4.2     8a1f3c9b2e7d

Notice both rows share the identical image ID, confirming they reference the exact same underlying image content; the repository column simply differs because this single image has been tagged under two separate, full names, which is entirely expected and not an indication of duplicated storage.

The <none> repository for dangling images

A repository value of <none> specifically indicates a dangling image, one with no tag currently referencing it at all, which happens most commonly when an existing tag is reapplied to a newer build, leaving the previous image's content intact on disk but without any name still pointing at it:

REPOSITORY   TAG       IMAGE ID
<none>       <none>    3f29a8c1d8e2
my-api       1.4.2     8a1f3c9b2e7d

Both the repository and tag columns show <none> together for this kind of image, since an image without a name necessarily also has no associated tag; this combination is the specific, recognizable signature of a dangling image worth checking for and cleaning up periodically as covered in dedicated disk usage content.

Multiple tags producing multiple listed rows

A single image with several tags applied to it appears as multiple separate rows in the default listing, one per tag, even though all of them share the identical underlying image ID and represent exactly the same content:

docker tag my-api:1.4.2 my-api:latest
docker images

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

This is worth understanding explicitly when estimating disk usage from a raw row count, since these two rows do not represent double the actual storage; they are two different names referring to the identical, single underlying image content.

Distinguishing registry, namespace, and repository name components

A fully qualified reference combines several distinct components, an optional registry hostname, an optional namespace or organization, and the repository name itself, and reading this combined string correctly matters when comparing references or troubleshooting a registry-related issue:

registry.example.com/myorg/my-api
└──────┬───────────┘ └─┬─┘ └─┬──┘
   registry hostname  namespace  repository name

docker images --format "{{.Repository}}"

The --format field named Repository actually returns this entire combined string, registry, namespace, and name together, rather than isolating just the final, bare repository name component, which is worth knowing when constructing a script that needs to parse out just one specific part of this combined reference.

Filtering and grouping by repository name

The reference filter, covered in dedicated CLI command content, matches against this same repository column, supporting wildcard patterns useful for finding every tag belonging to a specific repository name regardless of how many distinct tags currently exist for it:

docker images --filter "reference=my-api"
docker images --filter "reference=registry.example.com/myorg/*"

The second example matches every repository under a specific namespace, useful for reviewing everything pulled or built under a given organization's naming convention at once.

Common mistakes

• Assuming two rows sharing the same repository name but different tags represent meaningfully different, separately stored content, rather than recognizing the shared image ID confirms they are the identical underlying image.
• Counting rows naively to estimate disk usage, missing that multiple tags applied to the same image inflate the row count without correspondingly inflating actual storage.
• Not recognizing <none> in both the repository and tag columns together as the specific signature of a dangling image worth investigating or cleaning up.
• Assuming the Repository format field isolates just the bare repository name, when it actually returns the full combined registry, namespace, and name string together.
• Not using the reference filter's wildcard support to find every tag under a specific repository or namespace at once, manually scanning an unfiltered list instead.

The images repository column represents the name portion of a full image reference, with <none> specifically signaling a dangling image and multiple rows sharing an identical image ID confirming multiple tags pointing at the same underlying content rather than duplicated storage, both details worth reading correctly to avoid misinterpreting what a docker images listing is actually showing.