Docker Image Size Calculator (by base image + dependencies)
Estimate your Docker image size: pick a base (Alpine, Debian slim, Ubuntu, distroless), add dependency MB, get the total — plus a base-image size table and how to shrink it.
See step-by-step calculation
When to use this calculator
- Choosing between Alpine Linux (~7 MB), Debian Slim (~74 MB), and Ubuntu (~77 MB) as a base image before writing a Dockerfile for a Node.js microservice.
- Auditing an existing production image that has ballooned past 1 GB to identify which layer (OS, runtime, app code, or dev dependencies) contributes the most weight.
- Estimating registry storage costs on Docker Hub or Amazon ECR when deploying 50+ microservices that each pull a fresh image on every CI/CD run.
- Comparing multi-stage build strategies to verify that the final production stage drops build-time tools (gcc, make, npm cache) and meets a target size budget under 100 MB.
- Planning Kubernetes node disk quotas by forecasting total image storage when multiple pods share an image cache on the same node.
Common Docker Base Images: Uncompressed vs. Compressed Size (June 2025)
| Base Image | Tag | Uncompressed Size | Compressed (Pull) | Default Shell |
|---|---|---|---|---|
| scratch | — | 0 MB | 0 MB | None |
| alpine | 3.20 | ~7.8 MB | ~3.2 MB | /bin/sh (busybox) |
| debian | slim-bookworm | ~74 MB | ~29 MB | /bin/bash |
| ubuntu | 24.04 | ~77 MB | ~29 MB | /bin/bash |
| python | 3.12-alpine | ~52 MB | ~20 MB | /bin/sh |
| python | 3.12-slim | ~130 MB | ~50 MB | /bin/bash |
| node | 22-alpine | ~135 MB | ~52 MB | /bin/sh |
| node | 22-slim | ~235 MB | ~90 MB | /bin/bash |
| openjdk | 21-alpine | ~185 MB | ~72 MB | /bin/sh |
| golang | 1.22-alpine | ~240 MB | ~95 MB | /bin/sh |
Fuente: Docker Hub Official Images — docker image inspect, uncompressed sizes (junio 2025). El tamaño comprimido (pull) representa aprox. el 40–60 % del tamaño sin comprimir (gzip por capa). Fórmula: Total ≈ Base OS + Dependencias + Overhead (~5–15 MB).
How it works
How It's Calculated
Docker images are composed of stacked, content-addressable layers stored in the registry and assembled at runtime via a Union Filesystem (OverlayFS). Each RUN, COPY, and ADD instruction in a Dockerfile creates a new layer. The total uncompressed image size is:
Total Size (MB) = Base OS (MB)
+ Σ Dependency Layers (MB)
+ App Code Layer (MB)
+ Config / ENV Layer (MB)
+ Layer Metadata Overhead (≈5–15 MB)Compressed (registry) size is typically 40–60 % of the uncompressed size for most language runtimes, because gzip compression is applied per-layer on push/pull.
Registry Size (MB) ≈ Total Size (MB) × 0.45 (rough average)> Important: When you RUN apt-get install && rm -rf /var/lib/apt/lists/<em> in a single* chained command, deleted files are never written to a layer. If you split them into two RUN instructions, the deleted files still occupy space in the intermediate layer — a classic Docker gotcha.
---
Reference Table
Common base images (uncompressed docker image inspect size, June 2025 data from Docker Hub official images):
| Base Image | Tag | Uncompressed Size | Compressed (Pull) | Default Shell |
|---|---|---|---|---|
scratch | — | 0 MB | 0 MB | None |
alpine | 3.20 | ~7.8 MB | ~3.2 MB | /bin/sh (busybox) |
debian | slim-bookworm | ~74 MB | ~29 MB | /bin/bash |
ubuntu | 24.04 | ~77 MB | ~29 MB | /bin/bash |
python | 3.12-alpine | ~52 MB | ~20 MB | /bin/sh |
python | 3.12-slim | ~130 MB | ~50 MB | /bin/bash |
node | 22-alpine | ~135 MB | ~52 MB | /bin/sh |
node | 22-slim | ~235 MB | ~90 MB | /bin/bash |
openjdk | 21-alpine | ~185 MB | ~72 MB | /bin/sh |
golang | 1.22-alpine | ~240 MB | ~95 MB | /bin/sh |
---
Typical Cases
Case 1 — Minimal REST API (Go, multi-stage)
golang:1.22-alpine (240 MB) + source + modules (~80 MB) = ~320 MB (discarded)scratch (0 MB) + compiled binary (~12 MB) = ~12 MB totalCase 2 — Node.js Microservice (no multi-stage)
node:22-alpine = 135 MBnpm install --production (node_modules): ~110 MB.dockerignore to exclude node_modules on host, and prune devDependencies → can drop to ~160 MBCase 3 — Python ML Service (naive build)
python:3.12 (full Debian) = ~1,020 MBpip install torch torchvision = ~2,100 MBpython:3.12-slim + --no-cache-dir + multi-stage → realistic target ~900 MB---
Common Mistakes
1. Installing dev tools in the final stage — compilers (gcc, g++), curl, wget, and git left in the final image add 50–200 MB and increase CVE exposure. Use multi-stage builds: install build tools in a builder stage and COPY --from=builder only the artifact.
2. Splitting RUN cleanup into a separate instruction — running RUN apt-get install -y curl then RUN rm -rf /var/lib/apt/lists/<em> in separate lines does not remove the files from the layer that created them. Always chain: RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/</em>.
3. Ignoring .dockerignore — without a .dockerignore file, COPY . . sends the entire build context (including .git/, node_modules/, __pycache__/, test fixtures) to the Docker daemon, bloating the image and busting layer caches unnecessarily.
4. Using the full base image instead of -slim or -alpine variants — python:3.12 is ~1,020 MB vs. python:3.12-slim at ~130 MB. For most production workloads, the slim variant is sufficient and reduces the attack surface dramatically.
5. Not pinning image tags — using FROM node:latest can silently pull a larger image on the next build if the upstream maintainer ships a new major version with a heavier layer set. Always pin to a specific digest or version tag.
6. Overlooking layer ordering — placing frequently changing instructions (COPY . .) before slow, stable ones (RUN npm install) invalidates the cache for all subsequent layers on every build, forcing Docker to re-download and re-install dependencies even if they haven't changed.
---
Related Calculators
Calculation Example
Frequently asked questions
What is the actual size of the Alpine Linux base image in 2025?
alpine:3.20 image has an uncompressed size of approximately 7.8 MB and a compressed (registry pull) size of roughly 3.2 MB. This makes it the most popular lightweight base for production containers. It uses musl libc and BusyBox instead of glibc and GNU coreutils, which is why it's so small — but be aware that some Python packages with C extensions require glibc and may fail or behave differently on Alpine.How does Docker calculate image size when layers are shared between images?
alpine:3.20), that layer is stored once on disk and counted once in docker system df. The docker image ls command shows each image's full logical size, which can be misleading — docker system df gives the true disk usage after deduplication. Shared layers are never double-counted in storage.What is the difference between compressed and uncompressed image size?
docker image inspect) is what the container runtime unpacks into the container's filesystem — this is the size that matters for container startup and node disk usage. The compressed size (shown in Docker Hub and during docker pull) is the gzip-compressed layer size transmitted over the network, typically 40–60 % smaller. For example, node:22-alpine is ~135 MB uncompressed but pulls as ~52 MB compressed.How many layers can a Docker image have, and does layer count affect performance?
RUN, COPY, and ADD instruction adds one layer. Use && chaining in RUN commands and COPY --chown to minimize layer count. docker image history <image> shows exactly how many layers your image has and the size contributed by each.Does image size affect Kubernetes pod startup time?
imagePullPolicy: IfNotPresent) and keeping images under 200 MB are recommended practices for latency-sensitive production workloads.What is a multi-stage build and how much space can it save?
FROM instructions in one Dockerfile. Early stages install build tools and compile code; the final stage copies only the output artifact into a minimal base image. The intermediate stages are discarded and never pushed to the registry. For a Go application, a single-stage build might produce a ~300 MB image (golang base + source), while a multi-stage build with a scratch or alpine final stage produces a ~10–15 MB image — a reduction of over 95 %.How do I inspect what's inside each layer and which layer is the largest?
docker image history --no-trunc <image> to see each layer's size and the command that created it. For deeper analysis, tools like Dive (open-source CLI, github.com/wagoodman/dive) let you browse the filesystem diff of every layer interactively. docker system df -v shows total disk usage by image, container, and volume. For registry-side analysis, tools like crane (from Google's go-containerregistry) can inspect manifests without pulling the full image.What's the recommended maximum Docker image size for production?
gcr.io/distroless/base) average ~20 MB and are a benchmark for minimal production images. Keeping images small reduces CVE exposure, lowers registry egress costs, and improves CI/CD throughput.Does adding an environment variable (ENV) or label (LABEL) increase image size?
ENV and LABEL instruction creates a new layer that stores only the image manifest metadata — typically a few hundred bytes to a few kilobytes. The practical impact on image size is negligible (< 0.01 MB). However, they still add to the layer count (max 127), so it is good practice to group multiple ENV variables in a single instruction: ENV KEY1=val1 KEY2=val2 rather than two separate ENV instructions.Sources & references
Methodology & trust
Calculadora de tecnología revisada por el equipo editorial de Hacé Cuentas, contrastada con Docker Official Documentation — Dockerfile Best Practices, según nuestra política editorial y metodología.
Última revisión: June 20, 2026. Los parámetros se verifican periódicamente con las fuentes citadas.
Calculations run 100% in your browser. We do not store or transmit your data.
Indicative results. For critical decisions, consult a professional.
Rodríguez, M. (2026). Docker Image Size Calculator (by base image + dependencies). Hacé Cuentas. https://hacecuentas.com/docker-image-size-calculator
Contenido bajo licencia CC-BY 4.0 — reutilizable citando la fuente con enlace a Hacé Cuentas.