Why a Scanned Resume Returns Nothing at All

What the study found

We generated 108 resume PDFs across 12 formatting conditions and extracted each one with PDF.js. 11 of those conditions returned text. The scanned-image condition returned none.

Word recovery was 0%. Reading-order fidelity was 0%. Line welding was 0%, but only because there were no lines to weld. Email intact was 0%. Phone intact was 0%. Block integrity was 0%. Every metric that can be zero was zero.

When we inspected the raw extraction output, the document had produced literally zero text items. The reader did not misread anything. It found nothing to read.

That is the defining feature of this failure. Every other condition in the corpus, including conditions that broke reading order or fused unrelated lines, still delivered words to work with. The scanned page delivered an empty string.

The gap is not gradual

To understand how extreme this result is, compare it against the rest of the corpus. The next-worst word recovery was 96.9%, from the letter-spaced heading condition. Two-column layouts returned 97.9%. Table grids returned 97.6%. Even the condition with no space characters at all returned 99.8%.

Then the scanned page returned 0%. There is no gradient here. Every condition with a text layer returned nearly all of its words. The condition without one returned none.

This is worth stating plainly because most formatting advice treats all failures as roughly equivalent. Columns are bad, tables are bad, scanning is bad. The measurement says otherwise. Columns and tables cause real, measurable damage to reading order, but the words survive. A scanned page loses everything.

How a resume becomes a scanned image by accident

Most people who submit a scanned resume do not know they have done it. They wrote the document in Word or Google Docs, and somewhere between that moment and submission, the text layer was stripped. The usual paths are all innocent-looking.

The most common is scanning a printed copy. You print the resume, hand it to someone, and later scan it back in because the original file was lost. The scanner produces an image. Some scanners run OCR automatically, some do not. If yours did not, the result is a picture of text with no text behind it.

Photo-based workflows do the same thing. Taking a photo of a printed page and converting it to PDF produces an image-only file. So does using a phone's scanner app if it does not include an OCR step. Some fax-to-PDF services produce image-only output. And some PDF tools offer a 'flatten to image' or 'print to image' export that deliberately removes the text layer to lock down the document.

In each case the resume looks normal when you open it. You can see your name, your headings, your bullet points. But seeing is not the same as selecting, and selecting is the test that matters.

The ten-second test for a text layer

Open the PDF in any reader. Press Ctrl+A (or Cmd+A) to select all. If text highlights, there is a text layer and extraction can work. If nothing highlights, or the highlight covers the whole page as a single rectangle rather than following lines of text, you have an image.

A second check: copy and paste into a plain text editor. If the paste produces your name, your headings, and your bullet text, the layer is present. If it produces nothing, or a single gibberish character, the layer is missing.

This is the single most useful pre-submission check you can run. It costs ten seconds and it catches the one condition that loses everything. No amount of formatting adjustment can fix a file that has no text to format.

What OCR does and where it falls short

Optical character recognition reconstructs a text layer by examining the pixels, identifying shapes that look like letters, and writing the guessed characters back into the file. Tools like Tesseract and Adobe Acrobat can do this, and some scanner apps include it by default.

OCR solves the catastrophic case. A document with a guessed text layer is vastly better than one with no layer at all, because it gives extraction something to work with. But the guessed layer is not the same as the real one.

Accuracy depends on scan quality, resolution, font clarity, and the OCR engine itself. Ligatures, unusual fonts, small text, and low-contrast printing all reduce accuracy. OCR can introduce its own errors: swapped characters, merged words, split words, misidentified punctuation. These are the same categories of damage we measured in other conditions, except now they are introduced by reconstruction rather than by formatting.

The reliable fix is simpler: go back to the source document and export a real PDF. If the resume was written in Word, Google Docs, or any editor, exporting to PDF preserves the text layer exactly. The scanned version is always worse than the original export, even with good OCR.

How to avoid it entirely

The rule is short: always export from the source. If you wrote the resume in a word processor, use its PDF export. If you used a design tool, use its PDF export. Do not print and re-scan. Do not photograph the page. Do not use a flatten-to-image option.

If the original file is lost and you only have a printed copy, scan it at the highest resolution your scanner supports and run OCR before saving. Adobe Acrobat, Tesseract, and most modern scanner apps can do this. Then open the result and run the select-all test to confirm the layer is present.

If you are reviewing someone else's resume in a hiring workflow and extraction returns nothing, check whether the file is a scanned image before assuming the candidate made a formatting mistake. The fix is to ask for the original file, not to reject the application.

Where this sits in the larger study

The scanned page is the only condition in our 12-condition corpus that lost everything. It is also the only condition where the failure has nothing to do with how text is arranged on the page. Every other failure in the study is about reading order, line grouping, or word boundaries. This one is about whether there is any text to read at all.

That makes it the single highest-priority item on any resume checklist. Side-by-side layouts welded roughly 30.5% of lines. Letter-spaced headings lost 96.9% of words. Both are worth fixing. But both still delivered a document. A scanned page delivers nothing.

The complete study, including the corpus generator and every metric scored across all conditions, is published in the companion post linked below.