Skip to main content
Yoryantra
Home/Tools
← Back to Tools

Kubernetes Image Tag Checker

Trace container image tags, digests, pull policies, and registry references across Kubernetes manifests.

Paste workload manifests to examine container, init-container, and ephemeral-container image references.

Image Check Settings

Checks image strings

taglatestdigestregistryrepository

Checks

Parsing stays in this browser. No registry, image layer, or Kubernetes API request is made.

Output

Kubernetes image tag check output will appear here.
Manifest text is parsed in this browser. Image layers, registries, SBOMs, signatures, CVEs, and live cluster state are outside this check.

What an image reference actually fixes

Kubernetes accepts an image name with a tag, a digest, or both. A tag is a movable label; a digest identifies specific image content. When both are present, Kubernetes pulls by digest, so the digest is the part that fixes the content even if the tag later moves.

An image without a tag or digest has implicit latest semantics. That is different from writing a version tag such as v1.8.2, and it deserves the same release attention as an explicit :latest reference.

Pull policy can outlive an image edit

Kubernetes defaults imagePullPolicy when an object is first created. Changing a workload later from a version tag to latest does not automatically rewrite an already stored pull policy, so review the explicit field as well as the image text.

A registry name is not a trust decision

An explicit hostname makes the source easier to see, but it says nothing about provenance, vulnerability state, signature verification, or whether credentials are configured correctly.

Workload locations covered

Images are collected from containers, initContainers, and ephemeralContainers in Pods and common Pod-template workloads such as Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, and CronJobs. Generic controllers with a standard spec.template.spec Pod template are also read.

OCI image volume references and custom-resource fields that merely happen to be named image are not treated as container images. That boundary prevents unrelated YAML from being misreported as runnable containers.

Reading the result before a release

  1. Separate digest-pinned references from movable tags.
  2. Review explicit latest and implicit-latest references first.
  3. Compare the image text with the declared or expected default pull policy.
  4. Check whether an implicit registry is intentional for the target runtime.
  5. Use registry, signature, SBOM, and vulnerability controls for questions the manifest cannot answer.

Reference syntax worth checking

nginx:latest
nginx
registry.k8s.io/pause:3.10
registry.k8s.io/pause@sha256:<64-hex-digest>
registry.k8s.io/pause:3.10@sha256:<64-hex-digest>

The Kubernetes Images documentation explains default tags, digest behavior, and pull-policy defaulting in more detail.

Questions that matter more than “is it tagged?”

Does a version tag guarantee immutable content?

No. A registry can move a tag unless policy prevents it. A digest identifies the image content more precisely.

What happens when both a tag and digest are present?

Kubernetes uses the digest for the pull. The tag remains readable context, but it does not decide the fetched image content.

Does an omitted tag mean no tag at all?

Kubernetes treats an omitted tag as latest. The result therefore distinguishes the text form while warning about the same release unpredictability.

Why show imagePullPolicy next to the reference?

Pull behavior depends on both fields, and the API server defaults the policy when the object is first created rather than continuously recalculating it after image edits.