Search "should I send my resume as PDF or Word" and you get a few hundred articles that all say some version of the same thing. PDF is safer. Word is safer. It depends on the company. Every one of them is somebody's view, because answering the question properly means running both files through a parser and reporting what came back, and almost nobody writing those articles has a parser.
I had built one for something else. So I ran the file through it.
The setup
One resume. Same person, same words, same sections. Saved six ways, then put through the same extraction and scored out of 98, where the score is how much of the document survived into the structured record a recruiter actually searches.
| Saved as | Score | What it lost |
|---|---|---|
| Markdown | 98 | nothing |
| 95 | Missing links | |
| OpenDocument | 95 | Missing links |
| Plain text | 95 | Missing links |
| Rich text | 95 | Missing links |
| Word | 80 | Page header, Missing links |
The question assumes the answer is in the left column. It is not.
The Word gap is not Word
Word scores 80 and PDF scores 95, and the entire 15 point difference is one finding: page header.
The .docx in that table puts the name, email and phone number in the header region, which is exactly where a Word template puts them. Plenty of parsers discard the header before they start reading the body, on the reasonable theory that headers contain page numbers and document titles rather than content. So the contact details never arrive, and the record lands in the system with nobody attached to it.
Move that one line into the body and the file is still a .docx. Nothing about the container was ever the problem.
It runs the other way too, which is the part that settles it. A PDF laid out in two columns scores 68. Being a PDF saved it from nothing, because the extractor reads a two column layout in the order the text was drawn, not the order a human reads it, and the job titles end up interleaved with the skills list.
Rich text, corrected
When I first published this, rich text scored 60, and this section explained why: the file marks its section headings by making the text bold rather than applying a heading style, and my scorer only recognised a heading by its style. It ended with "Bold is not a heading. In any format."
That was my scorer being stricter than the rest of my own code. The importer that turns an uploaded resume into an editable one, and the reader for plain text files, had always treated a line that just says WORK EXPERIENCE as a heading. Only the scorer did not, so a clean rich text file was scored as a resume with no work history. On 30 September I changed the scorer: when none of a file's headings names a section, a line holding nothing but a section name now counts as a heading. In a file that styles some section names as headings and only bolds the others, the bold ones are still read as plain text, so set them all the same way. Rich text now scores 95 and ties with the other clean formats, and the two column PDF, which had been losing points for the same reason on top of its layout, went from 43 to 68. Whether a closed ATS reads a bold heading the same way, I have no way to test, and nobody outside those companies does either.
Markdown wins for a boring reason
Markdown is the only file that scored 98, and it is not because Markdown is magic. It is the only one of the six carrying a portfolio URL written out in full. The other four clean formats tie at 95 losing the same three points for the link none of them has.
The format did not earn that. The content did. Which is the whole point.
Keeping the numbers honest
Every number on the site is recomputed from the actual fixture files on each test run. This copy is not, which is why, when that test caught the change described above on 30 September, I corrected it here by hand. The published evidence lives in a typed array, a test reads the six real documents off disk, runs them through the same extraction the product uses, and compares. Change a weight in the scorer and the test fails with the new number in the assertion message.
it(`${row.file} still scores ${row.score}`, async () => {
const extraction = await read(row.file);
const score = scoreExtraction(extraction, recoverFields(extraction));
expect(score.value, `${row.file} score moved`).toBe(row.score);
});
There is a second test that matters more than it looks. It asserts the six files are the same resume, by comparing the name and email the parser recovered from each. The first version compared word overlap and read 0.84 across the six, because Markdown carries a URL and its own syntax while plain text carries neither. A threshold loose enough to pass that is loose enough to pass a different resume by the same author, so it compares recovered fields instead. If someone swaps a fixture, the scores stay plausible and the sentence next to them quietly becomes a lie. Those tests are what stand between the page on my site and being wrong six months from now. Neither can reach a copy like this one.
What to actually send
Send what the posting asks for. Somebody there knows what their system accepts, and ignoring an explicit instruction is a worse risk than either format.
Where nothing is specified, send a PDF exported from a word processor. Never one scanned or exported as an image: that file has no text layer at all and scores zero. Not a low score, nothing.
Then stop thinking about the format. Moving contact details out of a page header was worth 15 points on this document. Choosing between PDF and Word, with the layout already clean, was worth nothing at all. They tie.
The full write up, with the failure cases and the deduction table, is here: PDF or Word? The same resume, parsed both ways. The parser runs in the browser, so if you want to try it on your own file, nothing gets uploaded.
Top comments (0)