The photocopiers that changed numbers

In the summer of 2013, a German computer scientist named David Kriesel was looking at a scanned construction plan when he noticed that the room areas didn't match the original. The scan had replaced some area figures with figures copied from other rooms on the same plan, printed cleanly, in the document's own style, as if they had always been there. The scanner, a Xerox WorkCentre, was changing numbers.

Kriesel published his findings in August 2013, other users reproduced them, and the scale emerged: office machines that had been sold for years could substitute digits and figures in the documents they scanned (a 6 stamped where the page said 8, in his test sheets) while leaving the output looking crisp and trustworthy. Xerox first said the problem appeared only away from the factory-default quality settings; Kriesel then reproduced it at the default. Software patches followed. By then, years of archived scans made on affected machines were already sitting in filing systems, and no one could say which of their numbers were real. The bug is still cited in document-software circles, because nothing was broken in the way engineers normally mean it.

How JBIG2 compression substitutes characters

The culprit was JBIG2, a compression scheme for black-and-white scanned text, used inside the PDFs these machines produced. To understand what went wrong, compare it with the compression everyone knows. JPEG treats a page as a photograph and saves space by discarding fine detail; over-compress it and the page goes visibly soft, hazy around the letters. You can see that it happened.

JBIG2's lossy mode takes a different approach, and the difference is where the trouble starts. A page of text is mostly the same shapes repeated: every "e" looks like every other "e". So the algorithm cuts the page into little symbol-shaped patches, builds a dictionary of distinct shapes, and stores each occurrence as a pointer: "that dictionary shape again, here." The compression is excellent, and it rests on one judgement call: how similar two patches must be to count as the same symbol.

On the affected machines, at certain settings, that threshold was loose enough for one digit to match another's dictionary entry. The scanner then did precisely what its design said to do: stamped the wrong symbol, pixel-perfect, wherever the original had stood. There was no blur or haze to warn anyone; the page looked cleaner than a lossy scan usually does, because every character was a crisp dictionary stamp.

Why silent substitution is worse than visible blur

Kriesel's talks drew a broader conclusion than "Xerox shipped a bug": compression that understands content can rewrite content, and plausible output is the kind nobody checks. People compare a visibly degraded document against the original; a clean-looking one gets filed. Invoices, prescriptions and engineering drawings are all routinely scanned and then shredded, and all of them are places where a wrong digit is expensive. "The original went through the shredder after scanning" was standard office practice, built on the assumption that a scan is a faithful copy.

The affair changed practice. Lossy JBIG2 is now avoided outright in most archival scanning workflows, and the story became the standard citation for a principle that extends well past scanners: know what your compression does to your documents before you trust its output. Kriesel, for his part, became a minor legend in the German-speaking tech world (his conference talk on the affair, "Traue keinem Scan, den du nicht selbst gefälscht hast", is funny and still watchable), and "the Xerox bug" entered the vocabulary of everyone who builds document software.

What this means for your own scans and tools

Keep originals of documents that matter, on paper or as the untouched first-generation file, and treat every processed copy as a derivative. When a scanned number is load-bearing, a contract figure or a measurement on a drawing, verify it against the source rather than the scan's good looks. For catching unwanted changes between two versions of a document, a visual page-by-page diff is built for the job; it's pixel-based, so it catches changes a reader's eye would slide past.

It's fair to ask what the tools on this site do to your documents, since we compress PDFs all day. Our compressor re-encodes embedded images with JPEG-family compression, the kind whose failure mode is visible softness. There is no dictionary of shapes and no judgement about which characters are "the same", so it cannot change a 6 into an 8; push it too far and the page just looks over-compressed, which is obvious the moment you open the result. Its Extreme mode rasterises pages to hit brutal size targets, and the tool says so when it offers that: a bigger visual trade, still with no symbol substitution in it. The same goes for OCR, which does make judgements about characters: it writes its guesses into an invisible text layer for searching, while the pixels you look at stay the original scan. An OCR error can mislead a search, but it leaves the page itself alone.