A capture at 8.5 % of the size, and OCR reads it slightly better

Our own measurement had the capture at 6.7 MB against 1.1 MB for the browser's print export — noted on the comparison page and left there without comment. Looking into it turned up something better than a compression setting: for a page of text, dropping the colour costs nothing that matters and saves almost everything.

Measured 2026-08-04 · raw data

One page of text, three colour depths

1400 × 3200 px, lossless compression, OCR with Tesseract 5.3.4
ModeFile ShareWords read back
Full colour416 kB 100 %987
Greyscale243 kB 58 %989
Black and white113 kB 27 %989

Against the 1327 kB the current build produces as JPEG, the last row is 8.5 %. And the text recognition does not suffer — it reads back two words more than from the colour version, at 99.9 % agreement. That is not a coincidence: OCR binarises the image anyway. Handing it colour means handing it work it immediately throws away.

Why it will not be the default

The same setting on a page of photographs produces a structural similarity of 0.199 — the image is gone. No single value is right for both, which is why this belongs in the hands of whoever knows what they are capturing. A statute, a repository record, a page of tables: black and white. A figure, a map, a photograph: colour.

What is built, and what is not

The setting exists in 2.28.0, in both branches, and both browsers load that build. Alongside it the capture stopped always embedding JPEG: each tile is now compared and the smaller of lossless FlateDecode and DCTDecode is used.

It is not in either store yet. What is measured is the encoding and the recognition; what is not measured is a full capture in a real browser, because that needs a genuine input event the test setup cannot produce. No date is promised here — the stores currently serve 2.26.0 and 2.17.0, and this site does not make claims about when that changes.

What was checked and rejected

MRC, the standard behind small scanned PDFs, reaches a factor of eight to ten. It relies on JBIG2, which replaces similar glyphs with one shared pattern and has documented digit substitution. For a tool whose output is meant to serve as evidence, a file in which a year could quietly change is worth nothing — the saving does not enter into it. WebP and AVIF are not part of PDF at all.

The source details are untouched by any of this. Text layer, metadata and image are separate objects in the file; the RIS record and the checksum sit beside it. Changing how the image is stored does not change what the capture says about where it came from.