When Your Resume Is a Picture

Most parsing problems are partial. A column shreds, a date lands in the wrong field, a skill ends up in an unclassified block — damage you can see and repair. There is one failure mode that is total: a file with no machine-readable text in it at all. Upload it and the parsed record comes back essentially empty. Not scrambled. Empty.

This is rarer than the layout problems, and much worse when it happens, because nothing about the document looks wrong to you. It renders perfectly. You can zoom in on it. It just isn’t text.

What “text” means in a file

Text extraction — the first step of parsing, where software pulls a character stream out of your document — works on stored characters. A PDF that contains text stores, roughly, “draw the glyph A from this font at these coordinates.” The extractor can read the character code, so A comes out as A.

An image stores brightness values for a grid of pixels. There is no A anywhere in it. A human looking at the rendering infers a letter from the shapes; the file itself contains no such claim. Extraction on that file returns nothing, because there is nothing of the right kind to return.

Both can live inside a .pdf. The extension tells you the container, not the contents. This is the single most useful fact in this post: PDF is not one thing. A text-based PDF and an image-based PDF are as different, to a parser, as a document and a photograph.

The four ways a resume becomes a picture

You scanned it. Printed, put through a scanner or a phone scanning app, saved as PDF. Common when someone asks you to sign something and you re-send the signed copy as your resume, or when the only version you can find is on paper.

You exported it from a design tool as an image. Some export paths flatten everything to a raster layer, especially ones aimed at print or social sharing. The result is a PDF wrapping a single large picture.

You converted a screenshot. Screenshot the document, drop the image into a PDF. This happens more often than you’d expect when someone is fighting a broken export.

The fonts got converted to outlines. This one is the trap, because it does not look like an image problem. “Outline text,” “flatten transparency,” “convert type to paths,” and some print-oriented export presets replace each character with a vector drawing of its shape. The file is still vector, still crisp at any zoom, still small — and every letter is now a picture of a letter. The character codes are gone.

The fourth case is worth dwelling on, because it can affect part of a document. A designed header rendered as outlines above ordinary text below gives you a resume whose name and contact block extract as nothing while the job history extracts fine. The record arrives with an anonymous work history attached to no one.

What OCR does, and what it costs you

Optical character recognition looks at pixels and guesses characters. It exists, it is decent, and it is not a reliable safety net here for three reasons.

It may not run at all. Whether an OCR step sits in front of the parser is a per-system, per-employer configuration question. Some pipelines have one; assume yours doesn’t.

It introduces a new error class. Even good OCR confuses shapes: l/1/I, 0/O, rn/m, 5/S. On prose those errors are survivable — a reader repairs them. On the fields parsers care about, they are expensive. An email address with one wrong character is unreachable. A phone number with a transposed digit is wrong silently. A skill name spelled with a substituted character will not match a search for the real one, for the reasons in acronyms, synonyms, and spelling variants.

It flattens layout even harder. OCR output is generally a linear guess at reading order derived from pixel positions. Every reading-order problem described in why your two-column resume breaks gets worse, not better, because the extractor now has less structural information rather than more.

Treat OCR as damage control after the fact — the thing that might rescue a file you can no longer regenerate. It is not a reason to send an image.

The partial version: pictures inside a text document

Full image resumes are uncommon. Partial ones are everywhere, and each of these contributes exactly zero to the parsed record:

A skills radar chart, proficiency bars, or a five-dot rating scale.
A logo, badge, or certification seal instead of the certification’s name in words.
A “tech stack” strip made of tool icons.
A photograph with text set over it.
Any heading set as a graphic for typographic reasons.

The rule is simple and has no exceptions: if the only place a fact appears is inside a picture, the fact is not in your resume. Where a skill actually has to appear is the subject of where a skill has to appear to be found; a picture is not one of the places.

QR codes belong in this list too, along with the rest of the link question — see what a parser does with your links.

Getting real text back

If the test below shows an image, the fix is to regenerate rather than repair.

Find the source document, not the PDF. Rebuilding from the editable original is always faster than trying to recover text from pixels.
Export with “Save as PDF” or “Export as PDF” from the editor. Avoid anything labelled print-ready, flattened, outlined, or image-quality.
Turn off outline/flatten options explicitly if the export dialogue offers them. Type should stay type.
If the original is genuinely gone, retype it. It is an hour of work and it produces a file you can maintain. OCR-and-clean-up usually takes longer and leaves errors you won’t spot.
Never re-scan a printout as your submission copy, even a beautiful one.

If you must send an image for some other reason — a signed document, a portfolio piece — send it in addition to a text-based resume, never instead of one.

Check it

Open your resume in any PDF viewer and try to select a sentence with your cursor. Then press Ctrl-F (Cmd-F) and search for your own surname.

Text selects and search finds it: real text. Move on to the extraction test in how to test your resume like a parser would.
Nothing selects, or selection highlights a whole rectangle at once: it’s an image.
Some of it selects and some doesn’t: you have the partial case. Note exactly which regions won’t select — those are the parts that do not exist to a parser.
Selection works but the copied text is garbled: that’s a different failure, covered in the characters that extract wrong.

Two seconds, no tools, and it rules out the only parsing failure that loses everything at once.