Scans, Photos or PDFs: File Quality Requirements for Document Validation

Document scan quality requirements come down to three questions: can every character on the page be read, is the whole page in the frame, and is the file complete and unlocked. A flat scan at about 150 DPI or more, one document per file, all pages present and upright, meets the bar most text-extraction engines document. Anything below it should be sent back to the applicant with a precise request, not pushed into a validation run that will fail or, worse, return confident but wrong values.

This article is provided for informational purposes and does not constitute legal advice. Figures quoted come from vendor documentation read on 14 October 2026 and describe those products, not CheckFile. Consult a qualified professional for decisions about an individual case.

What "readable" means for a document file

A file is readable when software can recover the printed text and fields without guessing, and that depends on resolution, framing, orientation and file structure rather than on how the page looks to a person. A phone photo that is perfectly clear on screen can still fail if the text is only a few pixels tall.

Amazon Textract's best-practice guidance recommends high-quality images, ideally at least 150 DPI, and advises against converting or downsampling a file that is already a PDF, TIFF, JPEG or PNG before upload (AWS, Amazon Textract best practices). That second point matters at intake: a portal that silently shrinks every upload to save storage can degrade files that were fine when the applicant sent them.

Microsoft documents similar thresholds for its Read model, which is the OCR layer under its prebuilt ID, invoice and receipt models. The figures below are vendor limits, not universal rules and not CheckFile limits.

Source for the Microsoft column: Microsoft Learn, Document Intelligence Read model, input requirements. Both pages are versioned and change; recheck them before copying a number into your own intake rules.

Request, rescan or manual review: the decision table

The most useful rule for an intake team is to decide per defect, not per file. Each defect below maps to one of three actions: ask the applicant for a new file, ask for a rescan with specific instructions, or keep the file and send it to a person.

The pattern: a defect that destroys information is a request, a defect that only hides it from software is a rescan, and a defect that needs judgment is a manual review.

Three synthetic examples

These cases are invented to show the decision, not drawn from any customer file.

Example 1, the half-cropped payslip. An applicant sends a phone photo of a payslip. The net-pay line sits at the very bottom edge and the last digit is cut off. The reader returns "2 41" with low confidence. Action: request a new photo with the full page and a margin visible on all four sides. Do not accept the partial value.

Example 2, the two-page bank statement sent as one page. The PDF has one page; the footer reads "page 1/2". Action: request page 2. This is a completeness issue first, and a quality issue only if page 2 later arrives as a photo.

Example 3, the locked PDF from an employer portal. The file opens with a password the applicant knows but your system does not. Action: ask for an unlocked export or a print-to-PDF copy. Never ask applicants to send you the password in a message.

Telling applicants what to do

Applicants fail intake mostly because instructions are vague. A checklist sent with the request halves the back-and-forth, though no figure should be promised.

• Scan flat on a scanner or scanner app, at least 150 DPI, in colour, one document per file.
• For a photo, use daylight, lay the page on a dark flat surface, keep the phone parallel and fill the frame with a small margin.
• Send every page, in order, upright.
• Do not photograph a screen; send the original PDF.
• Remove the password before sending, or tell us the file is protected and we will give you a secure alternative.
• Do not edit, crop or filter with a beauty or contrast app.

On the forums where people discuss document uploads, the same questions come up: whether a phone photo is accepted as well as a scan, whether a screenshot of an online payslip counts, and why a perfectly readable PDF was refused. The honest answers are that a good photo usually works, a screenshot is weaker than the original file, and a refusal often comes from a technical limit such as size, lock or dimensions rather than from the content.

Confidence thresholds and the human fallback

A quality gate is only half of the intake; the other half is deciding what to do with uncertain extractions. Textract's guidance says business processes involving financial decisions might require confidence thresholds of 90% or higher, and that low-confidence results should be discarded or flagged for human scrutiny (AWS, Use confidence scores).

In practice, set one threshold per field type, not per file. A name or a date that fails the threshold goes to a person; a free-text address line can tolerate a lower one. Record which threshold applied.

Keep the original, and remember readable is not authentic

Store the file exactly as received, with a timestamp, and work on copies. If a rescan replaces a defective file, keep both and link them. That way a later dispute about what the applicant sent can be settled, and nobody has to rely on an enhanced image.

Readable also does not mean genuine. A crisp scan of a falsified document passes every quality check in this article. Quality triage prepares a file for validation; it does not test whether a document is authentic, and it should not be described as doing so. Where authenticity is a concern, treat it as a separate control.

Collecting more files than needed is its own risk: asking for a rescan should not become a reason to request extra documents. Data minimisation under Article 5(1)(c) of the GDPR applies, and the UK regulator publishes its own guidance at the ICO. Where a statutory check is involved, such as right to work, follow the route in the gov.uk employer guide; a good scan does not replace it.

Where this fits in the validation flow

File quality is step zero. After it comes completeness (are all required documents there), validity (dates, expiry, registers) and consistency (names, addresses and amounts agree across documents). For how extraction relates to those later checks, read Cross-Document Validation: Beyond OCR and IDP and the comparison in Best OCR software for document verification. The overall method is in the document verification guide.

Operations teams that collect files from applicants or suppliers can see how these checks are organised on the pricing and plans page, and how data is handled on the security page. The checks compare fields, dates and registers across documents; they do not prove that a document is authentic.

Frequently Asked Questions

What are the document scan quality requirements for validation?

A flat, upright, complete file with every page present, one document per file, and text large enough to read, which vendors express as about 150 DPI or a minimum text height of 12 pixels on a 1024 x 768 image. Limits differ by tool, so check the one you use.

Is a phone photo as good as a scan?

Often yes, if it is taken in even light, parallel to the page and fills the frame without cropping. A photo with glare, blur or cut edges should be retaken.

Should I accept a screenshot?

Prefer the original file. A screenshot loses resolution and page structure, and screenshots of screens can show moire patterns that hurt extraction.

Why does my PDF get rejected even though it is clear?

Typical causes are a password lock, a file larger than the limit, images outside the accepted dimensions, or missing pages. Remove the lock and resend as one document per file.

Does a good scan prove the document is genuine?

No. Quality only means the content can be read. Authenticity is a separate question that needs its own control.