Parse any Docker image reference into its individual components instantly. Decode registry, namespace, repository, tag, and digest with color-coded visualization. Build image references from scratch with our interactive builder. Supports bulk parsing of multiple image names.
Paste any Docker image reference and get an instant breakdown of every component -- registry, namespace, repository, tag, and digest -- with color-coded visualization for easy reading.
Parse multiple image references at once by pasting them one per line. Each image gets its own result card with full component breakdown, making it easy to compare and analyze images across registries.
Construct valid Docker image references from individual parts using the interactive builder. Enter a registry, namespace, repository, tag, or digest -- and watch the image name update in real time.
Automatic recognition of popular container registries including Docker Hub, GitHub Container Registry (ghcr.io), Amazon ECR, Google GCR/Artifact Registry, Azure ACR, Quay.io, and more.
Docker image names (also called image references) are the standard way to identify container images across registries, orchestrators, and CI/CD pipelines. Every time you run docker pull, docker run, or specify an image in a Kubernetes Pod spec, you are using a Docker image reference. Understanding the anatomy of these references is essential for working with containers, managing image versions, and configuring private registries.
A fully qualified Docker image reference follows this structure:
registry/namespace/repository:tag@digest
The registry is the hostname of the container registry (e.g., docker.io, ghcr.io, quay.io). When omitted, Docker defaults to Docker Hub (docker.io). The namespace is typically the organization or user account that owns the image, such as library for official Docker Hub images. The repository is the name of the image itself. The tag identifies a specific version or variant (defaults to latest when omitted), and the digest is an immutable, content-addressable identifier using SHA-256 hashing.
In Parse mode, paste one or more Docker image references into the text area and the tool will instantly break each one into its individual components. Click any example button to see how different registries and formats are parsed. Each result card shows a color-coded visualization and a detailed field grid. In Build mode, fill in the registry, namespace, repository, tag, or digest fields and the tool constructs a valid image reference in real time that you can copy to your clipboard.
nginx is actually shorthand for the fully qualified reference docker.io/library/nginx:latest. The image name encodes several pieces of information: the registry that hosts the image, the namespace or organization that owns it, the repository name, and optionally a tag or digest to pin a specific version. Image names are used everywhere in the container ecosystem -- in docker run commands, Dockerfiles (FROM instructions), Kubernetes manifests, Docker Compose files, and CI/CD pipeline configurations. Understanding how to read and construct image names correctly is a fundamental skill for anyone working with containers.
[registry/][namespace/]repository[:tag][@digest]. The registry is the hostname (and optional port) of the container registry, such as docker.io, ghcr.io, quay.io, or 123456789012.dkr.ecr.us-east-1.amazonaws.com. The namespace is typically an organization or user account (e.g., library for Docker official images, or mycompany). The repository is the image name itself (e.g., nginx, node, my-api). The tag follows a colon and identifies a specific version or variant, such as latest, alpine, v2.1.0, or 22.04. The digest follows an @ symbol and is a content-addressable SHA-256 hash like sha256:abc123.... Most parts are optional -- nginx alone is a valid reference that Docker expands to docker.io/library/nginx:latest.
nginx instead of nginx:1.25), Docker automatically assumes the latest tag. This means docker pull nginx is equivalent to docker pull nginx:latest. However, relying on the latest tag is generally considered a bad practice in production environments for several reasons. First, latest is a mutable tag -- it can point to different image versions at different times, meaning your deployments may pull a different image than expected. Second, it makes it impossible to know which exact version of an image is running without inspecting the digest. Third, it can cause inconsistencies when containers are scheduled across multiple nodes that pulled the image at different times. Best practice is to always specify an explicit tag (preferably a semantic version like nginx:1.25.3) or, even better, use a digest (nginx@sha256:...) for fully reproducible deployments, especially in Kubernetes and production CI/CD pipelines.
latest, v2.0, or alpine that is assigned to an image. Tags are mutable, meaning a tag can be reassigned to point to a different image at any time. For example, when a new version of an image is pushed with the latest tag, the old image that was previously tagged latest loses that tag. A digest, on the other hand, is an immutable, content-addressable identifier computed from the image manifest using SHA-256 hashing (e.g., sha256:a3ed95caeb02...). A digest always points to the exact same image content and can never change. You can use both together in a single reference: nginx:1.25@sha256:abc123.... For production workloads, digests provide the strongest guarantee of reproducibility and security because they ensure you always get the exact same image, preventing supply chain attacks where a tag could be overwritten with a compromised image.
myregistry.azurecr.io/myapp:v1.0 refers to an image hosted on an Azure Container Registry, and 123456789012.dkr.ecr.us-east-1.amazonaws.com/api-service:latest refers to an image on Amazon ECR. Docker distinguishes a registry hostname from a namespace by looking for a dot (.) or colon (:) in the first path component, or if it equals localhost. Without these indicators, Docker treats the first component as a Docker Hub namespace. To pull from a private registry, you typically need to authenticate first using docker login, which stores credentials in your Docker config file. In Kubernetes, you configure access to private registries using imagePullSecrets in your Pod spec, referencing a Secret that contains the registry credentials. Common private registries include Amazon ECR, Google Artifact Registry (GCR), Azure ACR, GitHub Container Registry (ghcr.io), GitLab Container Registry, JFrog Artifactory, and Harbor.
library namespace on Docker Hub, which is why nginx is actually shorthand for docker.io/library/nginx. Official images include popular base images and software like ubuntu, alpine, node, python, postgres, redis, nginx, httpd, and hundreds more. They are distinguished by having no namespace prefix when pulled (e.g., docker pull nginx vs docker pull mycompany/nginx). Official images undergo regular security scanning, follow Dockerfile best practices, provide comprehensive documentation, receive timely security updates, and are rebuilt automatically when base images are updated. They are generally considered the most trustworthy starting point for building container images. When you see an image without a namespace on Docker Hub, you can be confident it has gone through Docker's official image review process.
docker pull MyApp:latest -- Docker will return an error: "invalid reference format: repository name must be lowercase." This restriction applies to the namespace and repository parts of the image name, but not to the tag. Tags can contain uppercase and lowercase letters, digits, periods, hyphens, and underscores (e.g., myapp:Release-V2.1 is valid). Registry hostnames follow DNS naming rules and are also case-insensitive but conventionally lowercase. When migrating images or setting up CI/CD pipelines, ensure your image naming conventions use only lowercase characters for the repository path to avoid build and deployment failures. Our parser will flag uppercase characters in the repository path as a validation warning.
nginx:latest) or use the explicit hostname docker.io (e.g., docker.io/library/nginx:latest). For GitHub Container Registry, use ghcr.io/OWNER/IMAGE:TAG. For Amazon ECR, the format is ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/REPO:TAG. For Google Artifact Registry, use REGION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG, and for the legacy GCR use gcr.io/PROJECT/IMAGE:TAG. Azure Container Registry follows REGISTRY_NAME.azurecr.io/IMAGE:TAG. Quay.io (Red Hat) uses quay.io/NAMESPACE/IMAGE:TAG. GitLab Container Registry uses registry.gitlab.com/GROUP/PROJECT/IMAGE:TAG. For self-hosted registries, simply use your registry's hostname and port: myregistry.example.com:5000/myimage:latest. Our parser automatically detects and labels the registry provider, making it easy to identify where an image is hosted.
Check out our other free developer tools. Build Kubernetes manifests, parse AWS ARNs, and more -- all from your browser with no sign-up required.
Kubernetes YAML Generator →