Skip to main content
This lesson explains how Docker image tags work, how Docker chooses a tag when you don’t specify one, and best practices for pinning images in development and production. When you run an image without an explicit tag, Docker uses the latest tag by default. For example, this command:
pulled and ran the image referenced by the latest tag (at the time of writing, that pointed to Redis 8.6.1). To request a specific version, append the tag after a colon. For example, to run Redis 7.4:
The portion after the colon is the image tag. If you omit it, Docker assumes latest. To discover available tags and what each one represents, visit the image’s page on Docker Hub and check the “Tags” tab. That listing often includes short/long tags and descriptions so you can choose the correct variant (for example, alpine, slim, or a specific version).
A screenshot of a webpage titled "Image Tags" showing a bulleted list of supported Docker image tags and links (versions like alpine, trixie, bookworm, etc.). The page footer reads "Copyright KodeKloud."
Each image:tag you pull is stored separately on the host. If you pull both redis:6.1 and redis:7.4, both will appear in your local image list. To list images on your host:
To remove a specific tagged image:
This deletes only the specified tag/image; other tags of the same repository remain intact.
Tip: For reproducible builds and deployments, prefer versioned and variant tags (for example, redis:7.4-alpine). You can also pin to an image digest using the manifest digest (for example, redis@sha256:<digest>) to guarantee the exact image content.
Common commands and their purpose:
In production, avoid relying on the latest tag. latest is a moving target and may change when image authors push new releases. Pin deployments to a specific, immutable tag (for example, redis:7.4-alpine) or to an image digest (redis@sha256:<digest>) so you deploy the same image every time.
Examples of pinned tags:
Links and references:

Watch Video