Scan quality: send the full-resolution scan
Document AI reads the image you send. If that image is a compressed copy of a better one, the extraction is worse than it needed to be — and you saved nothing by compressing it.
What to send
Send the best-quality scan you already have. Not a re-scan, not an upscale — the original, before whatever compressed it.
The common failure is not a bad scanner. It is a good scan that was shrunk on the way to us: an MFP with aggressive compression turned on, a “small file” email preset, or a PDF re-saved to save space. The bytes came off; so did the character strokes.
Above roughly 200 DPI on a text document, more resolution buys nothing. We measured it: the same page scanned at 200 DPI with compression, at 400 DPI grayscale, and at auto-color produced identical transcripts, and the 400 DPI file was six times the bytes for zero improvement. It also takes longer to upload and longer to process. So this page is not telling you to send bigger files. It is telling you not to send smaller ones than you already have.
The floor: 150 DPI
Below about 150 DPI, character strokes start to merge and the engine's per-word confidence drops measurably. Between 150 and 300 DPI you are in the range Document Intelligence is designed for. Above 300, you are paying in upload time and latency for nothing.
| Effective resolution | What happens |
|---|---|
| under 150 DPI |
Accuracy is limited by the image, not by the engine. The response carries a
warnings.lowResolution entry naming the pages and their effective DPI.
|
| 150–300 DPI | The working range. This is where a normal office scan lands. |
| over 300 DPI | No measured accuracy gain on text. Slower to upload and to process; on very large documents some engines refuse the file outright. |
Effective resolution is the scanned image's pixel width divided by the page's width in inches — a US Letter page scanned to 1275 × 1650 pixels is 150 DPI. It is not the number in the scanner's settings if something re-compressed the file afterwards.
Scanner profiles by document type
There is no single correct setting, and a profile tuned for text visibly damages a photograph. These are the settings that measured best per document class.
| Document | Profile | Typical size | Why |
|---|---|---|---|
| Text invoices, forms, letters, contracts |
MRC compression on, 200–300 DPI, scanner's own OCR off | ~160 KB/page | MRC keeps text edges sharp while compressing the background. Turning the scanner's built-in OCR off matters — see below. |
| Mixed brochures, reports with charts |
300 DPI color, standard compression | ~400 KB/page | Keeps chart labels and small print legible without a photo-grade file. |
| Photos ID cards, product shots, damage photos |
300 DPI, standard compression, not the text profile | ~700 KB/page | A text profile applied to a photograph introduces visible artifacts in skin, hands and clothing — and those artifacts are what the model then describes. |
Turn the scanner's own OCR off
Most office multifunction printers write their own invisible text layer into the PDF. It is usually worse than it looks, and a file that already “has text” invites everyone downstream to trust it.
On an 85-page office scan we measured a multifunction printer's built-in layer at a 37% mean word error rate against the same pages read properly — every accented character lost, a quarter of the URLs mangled, and 23 of 222 four-digit years garbled. It failed bimodally by font: ordinary body text came through at 3–10% error while every bold heading and bibliography page collapsed into noise. Someone searching that PDF gets silent misses with nothing to tell them why.
Send us the scan without it. We read the image.
The warning in the response
When a page was read at under 150 DPI, AnalyzeDocument and
ExtractWithTemplate say so. The entry is additive — it is absent entirely
on a document that is fine, and it never changes the shape of anything else in the response.
{
"success": true,
"fields": [ ... ],
"warnings": {
"lowResolution": {
"threshold": 150,
"lowestDpi": 96,
"pages": [
{ "page": 2, "effectiveDpi": 96, "imageWidth": 816, "imageHeight": 1056 }
],
"message": "1 page(s) were read at under 150 DPI ..."
}
}
}
The same text also appears in engineWarnings, which is the array a workflow can
surface to whoever uploaded the document. Pages whose text was read from a real text layer are
never flagged — nothing was read from pixels there, so the pixel count says nothing.
This is about input, not output
Sending us a full-resolution scan does not mean getting a bigger file back. Our searchable-PDF output writes an invisible text layer onto your original document rather than re-rendering the pages, so the result comes back at roughly the size you sent. Input resolution and output size are opposite ends of the pipe, and improving one does not cost you the other.