Methodology

What we measure

57 tags of 25 official images (the library/ namespace on Docker Hub), chosen as popular tags across language runtimes, databases, web servers and base operating systems. The list is fixed in the site's configuration and grows slowly.

Sizes and layers per platform

Source: the public Docker Hub API (/v2/repositories/library/<image>/tags/<tag> and its /images list), checked daily; last checked 2026-11-01. For each platform it reports the compressed size of all layers (the amount docker pull downloads, before deduplication against layers you already have), the layer list with the build step that made each layer, the digest and the push date. “Layers” counts only layers that add files; metadata-only steps such as ENV or CMD are excluded. “Updated” is the tag's last push date on Docker Hub.

Unpacked size, files and directories

Measured by DockerState, for linux/amd64 only. We pull the image by its exact amd64 digest, export it with docker save, then read every layer: unpacked size is the sum of each layer's decompressed tar stream, which is close to what docker image ls reports with the classic storage driver. Files and where the bytes go come from replaying the layers in order, applying deletions (whiteouts), and summing regular file sizes in the final filesystem. Images are re-measured only when their amd64 digest changes; the date of the measurement is shown on each page.

Docker Hub's website shows the compressed size. We checked our compressed totals against it: they are the same number, from the same API.

Base OS and packages

From a software bill of materials (CycloneDX) generated by Trivy 0.76.1 from the exported image. The base OS is what Trivy reads from the OS release files; packages are those listed by the OS package database (dpkg, apk, rpm) plus language packages Trivy recognises (pip, npm, Go binaries, gems, crates, composer). Java archives (.jar, .war, .ear) are not analysed: identifying them needs a separate 1 GB lookup database. The OS packages of Java images are still scanned, but libraries bundled as jars are not counted. Images with no package database, such as BusyBox, show none; that does not mean they contain no software.

Known vulnerabilities

Every day we download a fresh Trivy vulnerability database and re-scan each stored SBOM against it, so counts change as new vulnerabilities are published and fixed, even when the image itself has not changed. Current database: 2026-11-01. Counts are findings: one vulnerability ID in one installed package. Severity is the one Trivy assigns, which prefers the distribution's own rating over NVD's. “With a fix” means a fixed version of the package exists upstream.

Limits. A scanner finds known vulnerabilities in recognised packages; it does not prove an image safe. Many distribution findings are low-risk or marked “will not fix”. Use these numbers to compare images and to see what a rebuild would fix, not as a security audit.

How we checked the numbers

• Compressed size and layers against Docker Hub. For every tag where our measured image and Docker Hub's current amd64 image have the same digest (46 tags in this build), we compare the compressed layer bytes we read from the image itself with the size Docker Hub reports. 46 of 46 match to the byte, and 46 of 46 have the same number of filesystem layers. This check runs on every build.
• Unpacked size against a running container. On 2026-10-26 we summed the apparent size of every regular file inside a running nginx:alpine container (each inode counted once): 62,732,265 bytes. Our layer replay of the same image gave 62,731,828 bytes; the 437-byte difference is files the container runtime writes at start (/etc/hosts, /etc/resolv.conf, /etc/hostname). Note that du on a compressing filesystem such as ZFS reports far less (40.5 MB here) because it counts disk blocks, not file sizes.
• Re-scanning the SBOM loses nothing. On 2026-10-26 we scanned the same nginx:alpine image twice: directly, and through the SBOM we store. Both runs returned the same 59 findings (ID, package and severity).
• Vulnerability counts. Counts come straight from Trivy's report on the stored SBOM; we de-duplicate a vulnerability reported twice for the same package and version and change nothing else.
• Unsupported distributions are left out. Trivy cannot read Fedora's package database, so a Fedora image would show zero packages and zero vulnerabilities, which would mislead. We measure AlmaLinux, which Trivy supports, instead.

Schedule

• Daily: Docker Hub metadata, vulnerability database refresh and SBOM re-scan, site rebuild.
• When a tag's amd64 digest changes: one anonymous pull of that digest, then measurement and a new SBOM. Pulls are paced and stop well below Docker Hub's anonymous rate limit.

Sources and licences

Data	Source	Terms
Tag sizes, layers, digests, push dates, pull counts	Docker Hub public API	Factual metadata; no README text or logos are copied
Unpacked size, files, directories, image config	Measured by DockerState from the images	Our own measurements
Packages, base OS, vulnerabilities	Trivy (aquasecurity/trivy) and trivy-db	Apache License 2.0; the database aggregates NVD (public domain), GitHub Advisory Database (CC BY 4.0) and distribution security trackers

The data behind the compare tool is published as /data/tags.json.