Introduction

When people ask how to see a Docker image’s contents, they usually mean one of two things: inspect the image metadata or browse the files that will exist inside a container. Docker gives you different commands for each job, so the most useful answer is to choose the inspection method that matches the question you are trying to answer.

Inspect Metadata with docker inspect

If you need configuration details such as environment variables, entrypoint, working directory, labels, or image ID, use:

docker inspect ubuntu:24.04

This prints JSON that describes the image configuration. It will not show a directory tree, but it is the right tool for questions such as:

• what command does this image start with
• which environment variables are baked into it
• what is the exact image ID

You can also format the output:

docker inspect ubuntu:24.04 --format '{{.Config.Entrypoint}}'
docker inspect ubuntu:24.04 --format '{{json .Config.Env}}'

That is faster than scrolling through the full JSON output when you only need one field.

Inspect Build Layers with docker history

To understand how the image was assembled, use:

docker history ubuntu:24.04

This shows the layer history, the commands that created each layer, and their approximate sizes. It is helpful when you are debugging unexpectedly large images or trying to understand where a package was added.

For example, a large RUN apt-get install ... line usually explains a big jump in image size. docker history does not reveal the final merged filesystem, but it does explain how the image got there.

Open a Shell and Browse the Filesystem

If your goal is to actually see files and directories, the easiest option is to run a shell inside a container created from the image:

docker run --rm -it ubuntu:24.04 bash

If the image does not include bash, try sh:

docker run --rm -it alpine:3.20 sh

Once inside the container, use normal shell tools:

pwd
ls -la /
find /etc -maxdepth 2 -type f

This is the most direct way to answer practical questions such as whether a file exists or where a config directory lives.

Inspect Without Running the Main Process

Some images start a server or a long-running application by default, and you may not want to launch it just to inspect files. In that case, create a stopped container and export its filesystem:

1docker create --name inspect-me ubuntu:24.04
2docker export inspect-me -o rootfs.tar
3tar -tf rootfs.tar | head -50
4docker rm inspect-me

This gives you a tar archive of the final container filesystem. It is useful in automated checks and when you want an offline snapshot.

You can also copy specific files out of a temporary container:

docker create --name inspect-me ubuntu:24.04
docker cp inspect-me:/etc/os-release ./os-release.txt
docker rm inspect-me

That is convenient when you only need a particular config file or binary.

Use docker save for Layer-Aware Inspection

If you want to inspect how the image is packaged internally, use docker save instead of docker export:

docker save ubuntu:24.04 -o image.tar
tar -tf image.tar | head -30

docker save preserves image metadata and individual layers. That makes it better for low-level analysis, while docker export is better for viewing the final flattened filesystem.

Common Pitfalls

The most common mistake is expecting docker inspect to show files. It only shows metadata. To see actual filesystem contents, run a shell, export the container, or copy files from it.

Another pitfall is assuming every image contains shell tools. Minimal images may not include bash, sh, or even common utilities such as ls. When that happens, use docker export or docker cp instead of interactive inspection.

People also confuse docker save and docker export. save preserves image layers and manifests, while export gives the final merged filesystem view. They solve different problems.

Finally, remember to clean up temporary containers after inspection. Use --rm when you can, or delete the container once you are done.

Summary

• Use docker inspect for metadata such as entrypoint, environment variables, and labels.
• Use docker history to see how the image was built and why it has its current size.
• Run a shell in a container when you need the fastest interactive file inspection.
• Use docker export or docker cp when you want filesystem access without running the application normally.
• Use docker save when you need the original image layers and manifests rather than the flattened filesystem.