# Native PDF vs Scanned PDF: Why the Difference Matters

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2023-05-22T19:33:55Z
- Updated: 2026-10-11T19:22:20Z
- Category: OCR basics
- Canonical: https://www.schemalaw.com/blog/native-pdf-vs-scanned-pdf

> Native PDF vs scanned PDF: one stores the characters that were typed, the other stores a photograph of paper. How to tell them apart and why to ask for native.

A native PDF is saved straight from the program that wrote the document, so it stores the actual characters. A scanned PDF is a photograph of paper, so it stores pixels. In the native PDF vs scanned PDF question, the difference matters because native text is exact, while a scan's text has to be recognized and checked.

Both open in the same reader and can look alike at normal zoom. They behave very differently once you search, quote, file or produce them. This post sets the two side by side, with the OCR'd scan as a third column, and explains why the native file is worth asking for.

## What is the difference between a native PDF and a scanned PDF?

A native PDF holds text as text: each character, its font and its place on the page, written by software that knew what the words were. A scanned PDF holds a picture of each sheet. The first can be searched and copied exactly. The second cannot be searched at all until OCR adds a reading of it.

You will meet other names for each. Native PDFs are also called born-digital, text-based, digitally created or "true" PDFs. Scanned PDFs are also called image-only or image PDFs; the post on why you cannot copy text from a PDF describes [what an image-only PDF is](https://www.schemalaw.com/blog/why-cant-i-copy-text-from-a-pdf#what-is-an-image-only-pdf).

A scan that has been through recognition forms a third kind. It is still a picture, but it now has text attached.

| | Native PDF | Scanned PDF | Scanned PDF with OCR text |
| --- | --- | --- | --- |
| What a page stores | Characters, fonts, positions | One picture | One picture plus recognized characters |
| Source of the text | The authoring program | None | Software's reading of the picture |
| Search | Exact | None | Works where the reading is right |
| Copy and paste | Exact, with rare font quirks | Nothing to copy | Whatever was recognized |
| Zoomed to 800% | Sharp | Blocky | Blocky |
| Typical size, ten typed pages | Tens or hundreds of kilobytes | Often a megabyte or more | Slightly larger than the scan |
| Shows ink signatures, stamps, handwriting | Only if they were added digitally | Yes | Yes |
| Proof of what the paper looked like | No paper was involved | Yes | Yes |

The last two rows are the scan's side of the ledger. A native file is the better source of words. A scan is the only record of a sheet of paper as it existed, with its ink, its stamps and its marginal notes. Neither replaces the other, and the third column gives you a scan's appearance with a rough version of a native file's convenience.

## Where native PDFs and scanned PDFs each come from in a law office

Native PDFs come from software: a word processor's save-as-PDF command, a billing system, an e-signature service, a bank's statement download. Scanned PDFs come from paper passing a camera: the copier, a fax line, a phone, a records vendor. A single matter folder can hold both, sometimes inside one file.

| Usually native | Usually scanned |
| --- | --- |
| Briefs and letters your own office drafted and saved as PDF | Anything signed in ink and sent back |
| Documents completed on an e-signature platform | Faxes, including fax-to-email attachments |
| Statements and invoices downloaded from a portal | Records copied by a provider or agency from paper charts |
| Reports generated by a database or case system | Old closed-file documents |
| Email saved or printed to PDF | Phone photos saved as PDF |
| Forms filled in on screen | Exhibits copied from a paper binder |

### Files that surprise you

- **A typed document that is really a scan.** Someone printed a letter, signed it, and ran it through the copier. It looks like a clean typed page and holds no text.
- **A native file flattened to pictures.** Some redaction and "secure" export routines convert each page to an image on purpose. The file began as native and no longer is.
- **A file that is both.** A motion drafted in a word processor with scanned exhibits behind it has native pages and picture pages in one file. The post on OCR for PDF documents covers [PDF documents that are part typed and part scanned](https://www.schemalaw.com/blog/ocr-for-pdf-documents#pdf-documents-that-are-part-typed-and-part-scanned), including pages that are mixed within themselves.

The lesson from that list is to judge pages, not files. Checking page one tells you about page one.

## Why is the text in a native PDF more trustworthy than OCR text?

The text in a native PDF is the set of characters the authoring program wrote, so reading it back involves no guesswork. OCR text is an inference from a picture. Every character in it was a judgment by software, and a small share of those judgments are wrong in ways the page does not reveal.

Consider a settlement figure in an agreement between two fictional companies, Brightwater Holdings and Tessler Group. In the native PDF, a search for `$1,250,000` finds the figure on page 6, every time, because those ten characters are in the file. In a scan of the signed copy, the recognized text might hold `$1,250,00O`, with a capital letter O at the end, or `$1.250,000`. The page picture looks perfect. The search fails, and a copied figure is wrong.

The same split appears when you search a pleading for an allegation, the statute it cites, and the remedy requested. Native characters stay as typed. On the scan, a broken citation or a misread allegation can send you to the wrong page, while the picture continues to read correctly.

Three consequences follow from that difference.

1. **Search results mean more.** A hit or a miss in native text reflects the document. A miss in recognized text may reflect the reading.
2. **Quotations need less checking.** Text copied from a native file matches the page, apart from line breaks and hyphens.
3. **Counts and comparisons work.** Comparing two native versions shows real edits. Comparing two recognized versions shows edits mixed with recognition noise.

### Native text is exact, not infallible

"Exact" means the text is what the file contains. It does not mean the text is free of problems.

- A font may lack a character map, so that a page reads normally and copies as symbols.
- The stored order may not match reading order, especially in multi-column layouts and tables.
- The file may contain text you cannot see on the page, such as white text or content outside the visible area.

Litigation tools make the same distinction under the labels "extracted text" and "OCR text". The post on e-discovery OCR explains [extracted text versus OCR text](https://www.schemalaw.com/blog/ediscovery-ocr#extracted-text-versus-ocr-text) and how review platforms treat each.

## Printing and scanning a native PDF: what the habit throws away

Printing a native PDF and scanning the printout turns exact text into a picture. You lose the characters, the sharpness, the links and bookmarks, and most of the small file size. What comes back from the copier is a degraded copy of something you already had in perfect form.

People do it for understandable reasons. A signature is needed, so the whole document is printed. Exhibits are on paper, so everything goes through the feeder together. Someone was taught that scanning "locks" a document. Or it is simply how the office has always assembled a filing.

| Lost by printing and scanning | Why it matters |
| --- | --- |
| Exact text | Search and copying now depend on OCR |
| Sharp type | Small print and footnotes blur |
| Small file size | The file may hit a portal or email limit |
| Links, bookmarks, table of contents | Navigation is gone |
| Structure for screen readers | The file is harder to use with assistive software |
| Straight, clean pages | Skew, specks and feeder marks appear |

Some courts say so directly. The District of Arizona's [guidelines for scanning documents](https://www.azd.uscourts.gov/content/what-are-guidelines-scanning-documents) state that only documents "which exist only in paper form are to be scanned into PDF format prior to e-filing", and that all others "must be converted to PDF directly from a word processing program, and be text searchable." The same page tells filers not to run OCR software on scanned documents, while other courts ask for searchable scans. That is one court's instruction; read your own court's.

### What to do instead

- **For a signature,** print and sign only the signature page, scan that page, and swap it into the native PDF in place of the unsigned one. Or sign electronically where that is accepted.
- **For a filing with paper exhibits,** save the brief as PDF, scan the exhibits, and combine the two files in a PDF program. Only the exhibits become pictures.
- **For redaction,** use a tool that removes the underlying text. Printing and scanning does remove it, at the cost of everything in the table above.

There are times a picture-only copy is what you intend to send. That is a decision to make once, knowingly, and the post on [converting a PDF to a non-searchable PDF](https://www.schemalaw.com/blog/convert-pdf-to-non-searchable-pdf) covers how and when.

## Asking the sender for the native PDF instead of a scan

When a scan arrives of a document that was plainly typed, ask the sender for the PDF as it was saved from the authoring program. Be specific about what you mean, because "send me the PDF" will get you the same scan again. A sender who drafted the document may still have the native file.

### What to say

A request that works names the source and the reason:

> Thanks for the signed agreement. Could you also send the version saved directly from Word, before it was printed? A PDF exported from the word processor is fine. We need the exact text for our comparison, and the scanned copy is not searchable.

For a records custodian or a bank, ask whether statements can be downloaded from the portal as PDFs, in place of copies printed and scanned by staff.

### What to check when it arrives

1. Select a word on three different pages. Individual words should highlight.
2. Zoom to 800%. Type should stay sharp.
3. Confirm it is the same version as the scan: same date, same page count, same closing clause.
4. Keep both. The native file is your source of text. The signed scan is your record of execution.

### When you will not get one

Sometimes no native file exists. The document was typed decades ago, received on paper by the sender, or handwritten. Sometimes the sender has it and will not send it. In litigation, the form in which documents are produced is governed by the applicable rules, any order, and whatever the parties agreed, and that is a question for your own analysis and not for this post.

When a scan is all there is, recognition is the next step. The post on [OCR for PDF documents](https://www.schemalaw.com/blog/ocr-for-pdf-documents) explains how to decide which files and pages need it. Schema Law takes the scan as it arrived, as a PDF, PNG or JPEG of up to 20 MB, and the [how it works section of the homepage](https://www.schemalaw.com/#how-it-works) shows the steps.

## What else does a native PDF carry that a scan lacks?

A native PDF carries more than text. It can hold document properties, working links, bookmarks, embedded fonts, form fields, comments, attachments and digital signatures. A scan carries none of these. Some are useful to you, and some are information the sender may not have meant to share.

| Carried by a native PDF | Use to the recipient | Risk to the sender |
| --- | --- | --- |
| Properties: title, author, creating application, dates | Clues to who made the file, with what, and when | Names and dates they did not intend to disclose |
| Links and cross-references | Click from a citation to its target | None in most cases |
| Bookmarks | Jump between sections of a long filing | None in most cases |
| Embedded fonts | The page looks the same on every machine | None |
| Form fields | Type into the form; read entered values | Field values that differ from what is displayed |
| Comments and markup | See reviewer notes | Internal notes left in by mistake |
| Attachments | Files carried inside the PDF | Unintended documents travelling along |
| Digital signature | A check that the file is unchanged since signing | None |

Read the properties with care. They are easy to change and are often rewritten by the last program that saved the file, so they suggest a history and do not establish one.

The risk column cuts both ways. Before your own native PDF leaves the office, look at what it carries beyond the visible page. The post on [hidden text in a PDF](https://www.schemalaw.com/blog/hidden-text-in-a-pdf) explains what can travel inside a file and how to find it.

A scan, by contrast, is what it appears to be: pictures of pages. That simplicity is why some people prefer to send scans, and why you pay for it at the receiving end with a file that has to be recognized before it can be searched.

## Try it on a real document

Upload a scanned PDF and export it as Word, a searchable PDF or plain text on the free plan. Your documents are never used to train an AI model. [Start free](https://www.schemalaw.com/api/auth/google)