Docker Image Size Calculator
Paste or open a Dockerfile to see roughly how big the image will be, which steps make it big, and what to change. Nothing is built.
Looking up base image and package sizes…
Reading the registry and package lists.
- FROM node:22 …
- RUN apt-get update
- RUN apt-get install -y ffmpeg
- COPY . .
- RUN npm install
- RUN npm run build
Get a closer estimate 0/2 ready
Add your project folder, or drop it here, to size the steps below. stays on your computer
- COPY your build folder Add your build folder to measure it
- npm package-lock.json Add package-lock.json
7 ways to improve this Dockerfile
-
Without --no-install-recommends, apt also installs the packages yours “recommend”, which most containers don’t need. Add the flag, then install any of them you really need by name.
apt-get install -y --no-install-recommends …
How the size is worked out
We read the Dockerfile the way Docker does: line continuations, build arguments, and every stage of a multi-stage build. Only the stages that end up in the final image count; earlier build stages are shown greyed out.
- Base image: the size its registry lists for each layer, for the platform you pick (x86-64 or ARM). This is the compressed download size.
- apt and apk packages: the installed size from the Debian, Ubuntu or Alpine
package list for that release, plus every dependency that isn’t already in the image. When
apt runs without
--no-install-recommends, recommended packages are counted too, because apt installs them. Packages removed again in the same step are left out. - Your files and app packages: add your project folder (or just the files the
panel asks for) and COPY steps are measured from the folder, following
.dockerignore, while npm, pip and dotnet steps are sized from the npm registry, PyPI and nuget.org. A package installed in a build stage counts on theCOPY --fromline that brings it into the final image. - Everything else: downloads, build output and anything still missing are marked “not counted”. Type a size into any of them to add it.
- Settings: ENV, WORKDIR, CMD and similar lines don’t add a layer, so they’re 0 bytes.
The total adds a compressed size (the base) to unpacked sizes (the packages), so read it as a
guide to what’s big, not as the exact number docker images will print.
The changes that save the most
- Start from a smaller base. A full official image such as
node:22includes compilers and tools; the-slimand-alpinevariants don’t. - Build in one stage, run from another. With a multi-stage build, compilers, dev headers and source code stay in the build stage and only the result is copied out.
- Install only what you need. Add
--no-install-recommendsto apt, and usenpm ci --omit=devfor Node apps. - Clean up in the same RUN. Remove
/var/lib/apt/lists, useapk add --no-cacheandpip install --no-cache-dir. Deleting in a later RUN doesn’t help, because the earlier layer still holds the files. - Keep junk out of COPY. A
.dockerignorefile stops.git,node_modulesand local secrets going into the image.
Frequently asked questions
How can you know the image size without building it?
Most of an image is its base image and the packages it installs, and both are published. The base image’s registry lists the size of every layer, and Debian, Ubuntu and Alpine list the installed size of every package and what it depends on. We add those up. If you add your project folder or files, we also measure what COPY brings in and look up your npm, pip and NuGet packages. Anything still unknown, such as downloads and build output, is marked “not counted”, and you can type in a size for it.
Why is my real image bigger than the estimate?
Three usual reasons. Steps we can’t size (downloads, build output, and COPY or package steps when you haven’t added your files) aren’t in the total unless you enter them. The base image is counted at its download size, which is compressed, while docker images shows the unpacked size on disk, which is larger. And package sizes are the installed sizes from the package list, which Debian’s own policy describes as an estimate that varies with the file system.
Which base images can it look up?
Public images on Docker Hub, GitHub (ghcr.io), Quay, Microsoft (mcr.microsoft.com), Amazon ECR Public and Google (gcr.io). For Docker Hub images we also read which Debian, Ubuntu or Alpine release the image is built on, so package sizes come from the right list. For other registries, pick the release yourself from the list above the results.
What does “already in image” mean for a package?
Some packages you install are already in the base image, so installing them adds nothing. We know a base image’s contents from its own build steps (Docker Hub lists them), the packages every Debian and Ubuntu image starts with, and, for Alpine, the package list inside the release file the image was made from.
Does it run my Dockerfile or upload my files?
No. Nothing is built or run. The Dockerfile text is sent to our server only to look up the base image and package sizes, and isn’t stored. If you add your project folder, it’s read in your browser: we add up file sizes there, following your .dockerignore, and only package names and versions from your lock files are sent to look up their sizes. Your browser may say it’s “uploading” the folder; that’s its standard wording for letting a page read it.
Which project files does it use?
Only what your Dockerfile needs. For npm it reads package-lock.json (dev packages are left out when the Dockerfile leaves them out, and so are packages built for other platforms). For pip, the requirements files named after -r, including the ones they include. For dotnet publish, the .csproj, the projects it references and Directory.Packages.props, or packages.lock.json if you use one. The panel under the results lists what this Dockerfile needs and what’s still missing.
How exact are the npm, pip and NuGet sizes?
Close, but not exact. npm sizes are the unpacked size the npm registry lists for each version. pip and NuGet sizes come from each package file’s own list of contents: the wheel pip would pick for your Python version and platform, and the files dotnet publish copies for your target framework (assemblies already in the runtime image are left out). Not counted: Python bytecode files pip writes while installing, packages built from source, and your own compiled code. A requirements file that doesn’t pin every package is resolved to the newest versions that fit, which may differ from what pip picks on the day.
Should I always use Alpine or slim images?
They’re smaller, but check your app on them first. Slim images are the same Debian with fewer tools. Alpine uses a different C library (musl), and some compiled packages, especially Python wheels, behave differently or need building from source there. The tip shows the size difference so you can decide if it’s worth it.
Where the numbers and tips come from
Sizes are looked up when you change the Dockerfile: base images from their registry (Docker Hub’s tag API, or the registry’s own manifest), packages from the distribution’s package list, which we re-read once a day. Every tip follows one of these pages, which we re-check daily:
- Docker: Building best practices
- Docker: Multi-stage builds
- Docker: Understanding the image layers
- Debian: apt-get(8) manual
- Alpine: apk(8) manual
- pip: Caching
- npm: npm ci
See Methodology & sources for how the checks work.