Skip to content

Docker Image Explorer

Opens an exported image tarball and shows each layer’s command, size and the files it added or deleted.

Opens an exported Docker or OCI image and shows what each layer actually contains — its size, the Dockerfile step that produced it, the files it adds, and the files it deletes from the layers below. It is how you find out why an image is three hundred megabytes.

🔒 Runs entirely in your browserdockerocilayersinspect

Drop an exported image (.tar)

From `docker save image:tag -o image.tar` or podman save. Parsed in this tab; nothing is uploaded.

Opens both docker save tars and OCI image layouts, aligning each layer with its Dockerfile step from the config history (steps marked empty_layer — ENV, CMD, LABEL — create no layer and are listed separately). Deletions are read from the OCI whiteout convention: a .wh.name entry removes name from the layers below it — the file still exists in the lower layer and still costs its bytes.

How to use it

  1. Export the image

    `docker save image:tag -o image.tar`, or the equivalent `podman save`. An OCI image layout works too.

  2. Drop the tar in

    It is parsed in a worker in this tab. Nothing is uploaded, which matters because an image tar contains your entire filesystem.

  3. Open the big layers

    Each row shows its size as a bar and its Dockerfile step. Expanding one lists the largest files it adds, and separately what it deletes and what it hides.

Common questions

I deleted the file in a later RUN — why is the image still big?

Because a deletion is itself a layer. The OCI whiteout convention writes a `.wh.name` entry that hides `name` from the layers below; the original file is still there, still shipped, still counted. Delete in the same `RUN` that created it, or use a multi-stage build.

Why do some Dockerfile steps have no layer?

ENV, CMD, LABEL, EXPOSE and friends change only the config, not the filesystem, so the image history marks them `empty_layer`. They are listed separately here so the layer numbering still lines up with what actually costs bytes.

Can it open an image straight from a registry?

No — it reads a local tar only. Pulling would mean this page authenticating to your registry, which is a different tool with a different threat model. `docker save` is one command away.

The size here does not match `docker images`.

They measure different things. `docker images` reports the on-disk size after the storage driver has deduplicated shared layers; this reports the uncompressed content of each layer in the export. Both are true; the second is the one that tells you what a `docker pull` transfers.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.