Your resume PDF might contain no text at all

There is a way to lose a resume that has nothing to do with its contents. Put it in a text box, save it as a PDF, and the file that leaves your hands can be a picture of a resume rather than a resume. It opens. It looks right. It scrolls. On a phone it is perfect. And a program asked to read the text inside it finds nearly nothing.

This is not a rare mistake and it is not a subtle one. It is what a word processor does when you lay a page out the way a page is laid out, and the result is a file that scores you on nothing.

The test takes ten seconds

Open the PDF. Select all the text. Copy it. Paste it into a plain text editor, or a plain note, or a search box.

If the text arrives, your file has text in it. If what arrives is a blank line, a stray fragment, or a page number and nothing else, then the words you can see are drawn rather than written, and anything reading the file programmatically will not find them.

The version of this test that travels best: on macOS, open the PDF in Preview and try to select a sentence. On Windows, the same in Acrobat. If you cannot grab a sentence with the cursor, there is no sentence for a parser to find either.

One practitioner described running exactly this test on their own CV and cover letters and finding that both "turn up almost entirely blank in .txt because I have been using text boxes". Having found the cause, they changed one thing: printing to PDF rather than saving to PDF, which flattens the page in a way that preserves the text.

Why the file looks fine to you

A PDF describes a page. It can describe that page as a grid of positioned glyphs, which is what a word processor produces when you are arranging a design, or it can describe the page as a stream of text with a font, which is what a program can read. The two files look identical and behave completely differently.

The second reason is quieter: even a file with real text can still be arranged in a way that scrambles it. Text in two columns does not come out in two columns; it comes out interleaved, so a sidebar of skills can land in the middle of someone's work history and a date can attach to the wrong job. Skills laid out in a table arrive as one unbroken run, so "PythonSQLTableauExcel" is what a search for SQL has to match against.

What the evidence supports, and what it does not

A resume parser who posted their own caseload reported parsing 3,835 resumes over 17 days, with 81 percent carrying at least one thing that damaged them in parsing. The ranked causes were a skills section flattened into one blob (41 percent), a name the parser could not locate (26 percent), em dashes that some parsers read as a stray character or drop the text beside (19 percent), decorative bullets arriving as garbage at the start of every line (18 percent), a two-column layout (11 percent), dates that do not name a month at both ends (9 percent), curly quotes a word processor inserted (8 percent), and section headings a parser could not classify (8 percent).

That is one person's account of their own caseload, and it should be read that way. It is a practitioner describing what their tooling produced, not a study of resume parsing, and the percentages describe their queue rather than the population. No published measurement of how often resumes fail to parse cleanly was found while writing this, and that absence is part of the answer: the failure is common enough that people meet it, and quiet enough that the industry has never had to count it properly.

What does not depend on the percentages is the test. Whether your file has text in it is not a matter of statistics.

What to change, in the order that matters

• Check the file before you send it. The selection test takes ten seconds and it answers the only question that matters here.
• Export by printing, not by saving. Print to PDF flattens the page and keeps the text. This is the single change that fixes a text-box CV, and it costs nothing.
• One column. The most damaging item on the parser's list after flattened skills, and the easiest to remove. Nothing is gained from a sidebar that a parser will read in the wrong order.
• Plain section headings. "Experience" and "Education" as words, not as graphics. A creative heading is a reasonable preference and an unreadable one.
• Replace the long dash with a hyphen. Word inserts em dashes on its own, and they are the character most likely to be dropped.
• Write the first screen for a reader in a hurry. A separate problem from parsing, and the one that decides more outcomes. The posting is the most useful preparation document you have and the structure is not what people mean by structure.

A file that cannot be read is a worse problem than a file that reads imperfectly, and it is also the cheaper one to fix. Check the file.

For what an applicant tracking system does with a file it can read, and the one statistic in this field that does not survive contact with its source, see the 75 percent claim is not real.