Web assets, measured
Every guide answers with a percentage.
That percentage describes one kind of image. A photograph, a screenshot and a logo do not behave alike — and the gap between them is far wider than the gap between the formats everyone argues about. These tools measure the file you actually have.
- Nothing leaves your browser
- Measured, not quoted
- Free, no account
Best format for each, at quality 75
WEBP saves 41%
WEBP saves 86%
WEBP saves 84%
Four sources. Four answers.
Asked when a small image should be inlined as base64 rather than requested as a file, four guides give four different thresholds. Every one of them is stated as though it were the answer. None of them knows your file.
- 4 kBone source
- 5 kBone source
- 10 kBone source
- 20 kBone source
The underlying factors are not in dispute — request overhead, the 33% base64 surcharge, the lost cache entry. No tool puts them together into a sum for the file in front of you.
Measured here, 2026-09-03
The picture matters more than the format.
Three files, all encoded at quality 75 with the same library. Between the best and worst result the spread runs from 23% to 86% — and it is the kind of picture, not the format, that decides where a file lands in that range.
A photograph
Continuous tone, no hard edges, no flat areas.
- jpg
- 180 kB−35%
- webp
- 164 kB−41%
- avif
- 214 kB−23%
Original 277 kB
A UI screenshot
Flat fills, hard edges, text — the opposite of a photograph.
- jpg
- 44 kB−75%
- webp
- 24 kB−86%
- avif
- 31 kB−82%
Original 179 kB
A flat graphic
Few colours, large uniform areas, crisp type.
- jpg
- 24 kB−65%
- webp
- 11 kB−84%
- avif
- 12 kB−83%
Original 68 kB
One caveat the page owes you, because it is the same one the tool makes: a single quality number means something different in each format, so these three encodes are three slightly different pictures, not one picture at one quality. That is precisely why a decision needs the size-over-quality curve rather than a single row — and why the honest comparison is between your options on your file. Encoded with ImageMagick 7.1.2 — libjpeg, libwebp, libheif/libaom.
What the tool does
- 1
You drop a file in
It is read by the page you are already on. There is no endpoint on this site that would accept an upload, which is a stronger guarantee than a promise not to keep one.
- 2
Three encoders run locally
libwebp and MozJPEG answer in about a second. libavif is 3.3 MB of WebAssembly and arrives behind them, so two of the three answers are on screen while the third is still compiling.
- 3
You get a verdict
Not just the smallest result: what the change costs in encoding time and browser coverage, and whether the saving is worth a change to your build at all.
Why you can check this
Nothing here asks to be believed.
- Encoders
- libavif, libwebp and MozJPEG, compiled to WebAssembly by jSquash — the same libraries the reference implementations use.
- Where it runs
- In this tab. The Content-Security-Policy on this site allows exactly one external host, and it is not an upload target.
- The numbers above
- Produced by design/assets/samples/measure.sh on 2026-09-03 and read from a JSON file at build time, so they cannot drift away from what was measured.
- What is still missing
- The size-over-quality curve, which is what turns three sizes into an actual verdict. It is the next milestone, and it is not pretended to exist here.
Measure the file you actually have.
One tool today. Font subsetting, the base64 threshold and srcset breakpoints are planned — and none will be listed before it works.