b2KIT

Docker Image Size Analyzer

Paste a Dockerfile and estimate layer sizes with optimization tips for smaller image builds.

Tested tool guide Tested browser tools Checked August 16, 2026

What Docker Image Size Analyzer does and how it behaves

A Dockerfile can indicate where image weight may come from, but it cannot disclose the finished byte count. This analyzer reads pasted Dockerfile instructions, assigns size estimates to the layers they imply, and presents optimization tips for size-relevant choices. Its most important boundary is the missing build data: base image contents, files copied from the build context, downloaded packages, and generated artifacts are not contained in the Dockerfile. The result is planning guidance, not a substitute for building and inspecting the image.

How the result is produced

1

Dockerfile-based estimation

The input is Dockerfile source, so the estimate can reason from FROM and filesystem-changing instructions such as RUN, COPY, and ADD. It has no byte-level evidence for referenced build-context files, remote downloads, package selections, or generated output. Any size assigned to those steps is therefore an estimate based on the text, not a measurement of their resulting layer archives.

2

Layer-aware recommendations

Optimization advice should be interpreted with Docker's immutable layer model in mind. Removing a file in a later layer does not remove its bytes from an earlier layer. Keeping temporary downloads and their deletion in one RUN step, or copying only runtime artifacts from a build stage, can reduce final image content when those techniques fit the Dockerfile.

Good uses

  • Screen a Dockerfile before a CI build to find instructions worth investigating for image growth.
  • Review package installation and cleanup steps that are split across layers and may preserve unwanted bytes.
  • Evaluate whether a multi-stage rewrite can keep compilers, source trees, and build-only dependencies out of the final stage.

Limits and checks

  • A mutable base image tag can resolve to different content over time, so the Dockerfile alone cannot establish its actual size.
  • The analyzer cannot determine the bytes included by COPY or ADD without the referenced build context and applicable .dockerignore rules.
  • Compressed registry transfer size, stored image content, and later container writable-layer growth are different quantities; do not treat one estimate as all three.

Common questions

Can this predict the exact final image size?

No. Exact size depends on the resolved base image, build context, fetched content, target platform, and actual command output. Build the image for its target platform, then inspect the resulting image and layer history. Even then, distinguish image content from registry transfer size because registry blobs can be compressed and already-present layers may be reused.

Does deleting files in a later RUN instruction recover the earlier layer space?

No. In an ordinary layered image, a later deletion hides the path from the resulting filesystem view but leaves its earlier bytes in the image. Creating and deleting temporary files within the same RUN instruction can keep them out of that step's final filesystem change. Multi-stage builds can also exclude build-only material from the final image.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools