Extracting Data From a Bad Scanned PDF: Where OCR Hits Its Limits

Before you run a bad scan through any OCR tool, measure it. An A4 page scanned at 300 DPI is roughly 2,480 × 3,507 pixels. At 150 DPI it is about 1,240 × 1,754. AWS's own guidance for Textract is to provide a high-quality image, ideally at least 150 DPI. Below that line you are not really doing OCR anymore — you are betting. The three-second version: open the PDF, zoom to 100%, and try to read the cents of the total. If you can't, the model can't either.

The second thing worth knowing before you start is that the failure mode has changed. Old OCR produced obvious garbage — `1NV0lCE N¤`. Modern AI extraction produces a clean, plausible invoice number that simply isn't on the page. The KIE-HVQA benchmark, built specifically from ID cards, receipts and invoices degraded with motion blur and low contrast, found that multimodal models "fail to perceive visual degradation, leading to hallucinations"; the authors' tuned 7B model gained 22 percentage points of hallucination-free accuracy over GPT-4o on that set. Related work on lossy inputs describes the same thing: models emit "fluent yet incorrect text without signaling uncertainty". So the useful question isn't *which OCR handles bad scans best*. It's *is this file above or below the line, and which fields do I verify by hand*.

The 30-second triage

Run this before you upload anything. It costs nothing and saves the round trip.

1. Is there even a text layer? Press Ctrl+F and search for a word you can see on screen. If it's found, the PDF is digital, not scanned — no OCR needed, and any tool that re-OCRs it is degrading your data.

2. Check the pixel size. Export one page as an image, or look at the page dimensions in your viewer's document properties. A4 is 8.27 × 11.69 inches, so:

300 DPI → ~2,480 × 3,507 px (comfortable)
200 DPI → ~1,654 × 2,339 px (workable for clean, ≥10pt print)
150 DPI → ~1,240 × 1,754 px (the floor)
below that → expect character-level errors you won't see

3. The smallest-character test. At 100% zoom, find the smallest thing you actually need: the cents, the VAT number, the reference code in the footer. Readable to you at 100% is the practical proxy for readable to the engine.

4. Geometry. Are all four corners of the page in frame? Is the text upright rather than rotated? Table extraction in particular assumes upright text — a skewed photo turns a clean table into interleaved rows.

5. Contrast. Faded thermal receipts, third-generation photocopies and grey-on-grey faxes fail for a reason resolution can't fix: the characters aren't separable from the background at any zoom level.

Why 300 DPI keeps coming up

300 DPI is the standard archival and OCR baseline in library digitisation guidance, and scanner vendors give the same number, with the caveat that fonts under about 10pt do better at 400 DPI. Going to 600 DPI buys you very little on normal print and quadruples the file size. So the practical target is: 300 DPI, greyscale, flatbed for anything you plan to extract structured data from, and 400 DPI only for small print such as line-item detail on dense supplier invoices.

Note the gap between the two numbers in this article: 150 DPI is the *engine's* floor, 300 DPI is the *quality* target. Files between them usually work but concentrate their errors exactly where it hurts — small digits.

The trap nobody tells you about: WhatsApp compression

This one is worth checking first if your documents arrive through a phone. WhatsApp scales images sent through the photo picker down to roughly 1,600 pixels on the longest edge and compresses them hard. Do the arithmetic on an A4 page: 1,600 px ÷ 11.69 in ≈ 137 DPI — under the 150 DPI floor before the JPEG compression has even started chewing on the character edges.

The fix is free and takes one tap: send the file as a document (the paperclip → Document option), not as a photo. Files sent as documents are not resized or recompressed. Same phone, same photo, same page — and suddenly the smallest digits survive. If you're routing supplier invoices or IDs through a WhatsApp inbox, this single habit change is usually worth more than switching OCR engines.

What actually fixes a bad scan, in order of effort

Work down this list and stop at the first step that works. Most teams skip straight to step 6, which is the expensive one and rarely the answer.

Ask for the original file. The supplier almost always has a digital PDF. Ten seconds of asking beats an hour of forensic OCR. This also removes the OCR step entirely, since a digital PDF can go straight to structured output — the same route described in How to Automatically Convert PDF to Excel with WhappScan AI.
Re-scan at 300 DPI in greyscale on a flatbed. Not colour (bigger, no accuracy gain), not pure black-and-white (destroys faint strokes).
If it must be a phone photo: flat surface, natural light, no flash, all four corners visible, camera parallel to the page. Flash on a glossy invoice creates a blown-out patch exactly where the total usually sits.
Send it uncompressed — as a document, per the section above.
Pre-process: deskew, crop to the page, raise contrast. Worth it for a batch of a hundred identical bad scans; not worth it for one.
Only then change tool. And if you do, understand what you're changing: fixed-coordinate template OCR breaks the moment a degraded scan shifts the layout by a few millimetres, which is a different problem from raw character accuracy — see Why Per-Supplier OCR Templates Break and OCR Accuracy in 2026: Why AI is Better than Traditional Software.

The decision rule: when to stop trying

Use your own numbers, not benchmark numbers. Take the fully loaded cost per minute of the person doing the work — salary plus employer costs, divided by worked minutes — and measure two things on a sample of ten documents:

A = minutes to key the document in by hand, start to finish
B = minutes to review and correct the extracted output

If B is more than about 60% of A, automation on *that class of document* is not paying for itself, and the answer is upstream: fix the scan, or fix how the document arrives. If B is under a third of A, keep going and put the saved time into the verification step below.

The rule matters because bad scans don't fail uniformly. A batch where 90% of files are clean and 10% are photocopies of faxes should be split, not averaged: automate the 90%, route the 10% to a human queue, and stop measuring the blended figure that hides both.

Fields you should never accept blind from a degraded scan

On a good scan, spot-checking is enough. On anything below 200 DPI, check these every time — they are the ones where a single wrong character is both invisible and expensive:

Amounts and cents. `1` vs `7`, `3` vs `8`, `5` vs `6`, and a misread decimal separator.
Tax IDs, VAT numbers, IBANs. Character-level, no context to self-correct from.
Dates. A misread month silently moves an invoice into the wrong quarter.
Quantities and unit prices on line items, usually printed smallest.
ID document numbers and MRZ lines, where a wrong digit breaks the whole downstream record.

The cheap defence is arithmetic, not proofreading. Most of these fields validate themselves: net + VAT − withholding should equal the total; Spanish NIF/NIE letters, IBANs and EU VAT numbers all carry check digits; line items should sum to the subtotal. Run those three checks automatically and a hallucinated number usually announces itself without anyone re-reading the page. That is the practical middle ground between trusting the model blindly and re-keying everything, discussed further in Human Validation vs AI in Data Extraction.

The short version

A bad scanned PDF is not one problem, it's three: too few pixels, too little contrast, and bad geometry. Only the first is measurable in advance, and it's the one that decides whether the other two matter. Measure it before you spend money, fix it at the source when you can, and let checksums — not eyeballs — catch what gets through.

If you want to see exactly where one of your own files sits, the fastest test is to run it: upload an invoice, an ID or a receipt and see what comes back, field by field, in a few seconds. Try the free extractor — no signup.