Reading Container Image Sizes in MiB and MB
You open the registry UI, see a service image listed at 412 MiB, then read the platform report that says the same image is 432 MB, and for a moment it looks like somebody pushed the wrong tag. Nothing is wrong. Registry front-ends such as Harbor, GitLab's container registry and Artifactory format layer and manifest sizes in binary units, while build reports, vendor pages and most size budgets are written in decimal megabytes. The two numbers describe the same bytes on two different scales.
That 4.86% is small enough to ignore on an Alpine base and large enough to matter on a fat Python or JVM image, where it moves the headline number by tens of megabytes. When a size budget is written into a pipeline gate, the gate and the dashboard have to agree on which scale they are using, or builds start failing for arithmetic reasons instead of real bloat.
Registries Format in MiB
Reports Speak MB
Two Sizes per Image
Converting Image and Artifact Sizes Step by Step
The workflow below matches what you actually do when a build gets bigger and you need one number everyone can argue about.
Copy the Figure from the Registry
Take the size your registry or artifact browser shows for the tag — that is the mebibyte value. Type it into the MiB field; a comma or a dot both work as the decimal separator, and spaces are ignored.
Read the Megabyte Equivalent
The MB field updates while you type, with no button to press. Values are shown to eight decimals and grouped with thin spaces, so 1 024 MiB reads cleanly as 1 073.741824 MB.
Paste It into the Ticket
The copy button on either field puts the bare number on your clipboard with no unit or spacing attached, so it drops straight into a size-regression issue, a changelog line or a pipeline threshold.
Go the Other Way
Press swap to turn the page into an MB to MiB converter — useful when a vendor publishes a decimal size and you need to predict what your registry will display. Either dropdown is searchable, so a layer quoted in KiB or a whole repository quoted in GiB converts on the same screen.
Base and Application Image Sizes Side by Side
These are representative uncompressed sizes for widely used official images. Tags move, so treat them as the order of magnitude rather than today's exact byte count — the point is how the gap between the two columns scales with the image.
| Image | Reported size (MiB) | Same size (MB) |
|---|---|---|
| alpine:3.20 | 7.8 MiB | 8.18 MB |
| nginx:alpine | 47 MiB | 49.28 MB |
| python:3.12-slim | 124 MiB | 130.02 MB |
| node:22-alpine | 133 MiB | 139.46 MB |
| postgres:16 | 425 MiB | 445.64 MB |
| python:3.12 (full Debian) | 1 020 MiB | 1 069.55 MB |
Read the last two rows together and the case for a diet writes itself: the difference between the full Debian Python image and its slim variant is roughly 896 MiB, or about 940 MB, pulled onto every node in the cluster on every rollout. Meanwhile the MiB-versus-MB gap on the Alpine row is under half a megabyte — which is exactly why the unit question only becomes worth arguing about once your images are large.
Layer-Scale Precision
Eight decimal places survive small layers: a 3.2 MiB config layer converts to 3.3554432 MB without being rounded to nothing.
Both Fields Are Live
Neither box is read-only. Type the target MB budget on the right and the MiB ceiling your registry will show appears on the left.
Any Unit on Either Side
Search the dropdowns for GiB, KiB, GB or bytes when a manifest, a layer blob and a repository quota are all quoted differently.
Clipboard-Ready Numbers
Copying gives you the digits alone — no unit suffix to strip before it goes into a YAML threshold or a spreadsheet cell.
Container Image Size Questions
Why does the size in my registry never match what the Docker CLI prints?
Two separate reasons stack up. First, the registry stores layers gzip-compressed, while the local view reports the extracted size on disk — for a text-heavy application layer the compressed copy can be a third of the extracted one. Second, the two views often use different unit bases, so even identical byte counts print as different numbers. Convert to a single scale before you conclude anything is broken.
If ten images share the same base, is the registry storing that base ten times?
No. Layers are content-addressed by digest, so a shared base layer is stored once and referenced by every manifest that includes it. That is why the sum of the per-image sizes in a repository listing is almost always far larger than the storage the repository actually consumes — and why pinning every service to the same base tag is a cheap win.
My registry quota keeps filling up even though we only ship a few releases — what is eating it?
Usually the per-commit tags nobody ever deletes. A pipeline that pushes one image per merge on a busy repository will add hundreds of tags a month, and each one that changed an application layer pins a fresh blob. Convert your average layer delta to MB, multiply by pushes per month, and you get the real growth rate — then set a retention rule that keeps release tags and expires the rest.
Which figure belongs in a size budget — the pushed size or the size on disk?
It depends on what the budget protects. If you care about cold-start and rollout speed, gate on the compressed pushed size, because that is what crosses the network. If you care about node disk pressure and image garbage collection, gate on the extracted size. Whichever you pick, state the unit in the policy — "under 300 MB" and "under 300 MiB" differ by nearly 15 MB.
How much does moving to a slimmer base image realistically save?
Going from a full distribution base to its slim variant typically removes several hundred MiB of compilers, docs and locales; going further to a minimal or distroless runtime can cut what remains again. The saving is bounded by your own dependency tree, though — if the application layer is 400 MiB of node modules or site-packages, no base image swap will rescue it, and a multi-stage build that ships only the built artefact will do far more.
No comments yet. Be the first to comment!