When a scanned PDF is too big for an upload form, the usual fix is to downsample the page images. The open question is how far that can go before fine print such as footnotes, form labels or the line under a signature box stops being readable. To get a number, a self-made test page was measured on 2026-11-06 on an Apple M4 Mac. Everything below comes from that one page, one run per setting, so treat the numbers as a single data point and not a rule.
How I forced each downsample target
The test page is a full A4 image at 2480×3508, which is 300 dpi. It holds four Chinese sentences and four English sentences set at 12, 10, 8 and 6 pt, in Hiragino Sans GB. A scanner look sits on top, with noise and a slight blur, and the page is saved as JPEG quality 90, so the PDF starts at 1,591,319 bytes. The text is fictional. Ghostscript 10.07.1 then forced the image down to exactly 300, 200, 150, 100 and 72 dpi. The presets leave an image alone until it is about 1.5 times the target, so the threshold is set to 1.0 to make every step really happen:
gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook \
-dDownsampleColorImages=true -dColorImageResolution=100 \
-dColorImageDownsampleThreshold=1.0 \
-dGrayImageResolution=100 -dGrayImageDownsampleThreshold=1.0 \
-o out.pdf in.pdf
Each output was rendered back at 300 dpi and every text block went through the macOS built-in text recognition with language correction on. English also went through Tesseract 5.5.3 as a second opinion. Accuracy is 1 minus edit distance divided by the length of the original text, spaces removed. One caveat: language correction can guess a blurry word right, so the macOS numbers are probably a bit kind.
Down to 150 dpi nothing broke
150 dpi was not where Chinese small print started to suffer. At 300, 200 and 150 dpi, every size from 12 down to 6 pt scored 99% or higher in both languages. The worst cell in those three rows was Chinese 6 pt at 150 dpi with 99.1%, and the 300 dpi version also had one at 99.1% (Chinese 12 pt), so one misread character is noise here. The file sizes are the reason this matters. The page went from 624,930 bytes at 300 dpi to 280,609 at 200 and 167,933 at 150, about a quarter of the 300 dpi file, with nothing lost for OCR.
This is the 8 pt line in both languages. The top three rows look the same to my eye, the 100 dpi row shows Chinese strokes starting to merge, and the 72 dpi row is a blocky mess where the English is still guessable and most of the Chinese is not.
Chinese small text started failing at 100 dpi
At 100 dpi Chinese 8 pt dropped to 96.3% and Chinese 6 pt to 81.3%, so close to one character in five was wrong. Two of the misreads: 清晰 (clear) came back as 清断, and 逾期 (overdue) came back as 適期. English at the same dpi was fine, with 6 pt still at 99.1% in macOS OCR and 94.3% in Tesseract. The size did halve again, to 87,346 bytes. My guess for why Chinese goes first, and it is a guess, is arithmetic: 6 pt at 100 dpi is about 8 pixels tall (6 × 100 ÷ 72), and a character with ten or more strokes may not keep its strokes apart in 8 pixels, while Latin letters have far fewer strokes to keep apart.
English held on until 72 dpi
At 72 dpi the file only shrank to 61,010 bytes, 26,336 bytes less than at 100, and the text paid for all of it. Chinese read 71.0% at 12 pt, 41.1% at 10 pt, 46.7% at 8 pt and 0% at 6 pt. Part of those Chinese scores comes from the recognizer skipping whole lines rather than misreading them, which may be why 10 pt scored lower than 8 pt, and I have not found a clean way to separate the two. English kept 100% at 12 pt, 98.3% at 10 pt and 84.7% at 8 pt, then fell to 11.3% at 6 pt. Tesseract agreed on the trend, with 99.1, 94.3, 76.0 and 41.1% from 12 down to 6 pt.
A separate two-page scan-style sample compressed the same day showed it in practice: at the 72 dpi level, 6 pt recognition was 41.5% with the ImgIng screen preset and 7.6% with Ghostscript /screen. The browser tool in that run, ImgIng https://imging.ai/ , runs PDF compression in a desktop browser and labels its presets by target dpi, 72 for screen and email, 150 for ebook and 300 for print, and it leaves images that are already below the preset alone. So for a scan that has fine print, 150 is the floor I would pick, or the ebook preset in whatever tool is open, and 100 only when the document is English and nothing on it is smaller than 8 pt. I would not trust 72 for anything someone has to read later. What I still have not tested is a real scanner file with a different font, and Chinese in Tesseract, which this machine does not have installed.
Top comments (0)