Correction, 17 October 2026. Earlier versions of this article said we had tested the same resume as PDF and Word across five ATS (Workday, Greenhouse, Lever, iCIMS and Taleo) and gave a parse-quality percentage for each. We have no records of that test, so we have removed the table and the figures, along with an unsourced claim about how those vendors upgraded their PDF parsers. The article now rests on how the two formats store text and on a PDF-versus-Word comparison we did run, in October 2026, with our own scanner.
"Should I send my resume as PDF or Word?" is one of the most-asked, worst-answered questions in career advice. The honest answer: both can work, and what decides it is how the file was made. Here is how each format stores your text, where each one breaks, and what we saw when we compared them ourselves.
The historical context
Older career advice said "always Word, PDFs break ATS parsing." That advice comes from a time when extracting text from PDFs was less dependable than it is now.
Today most application portals accept PDF uploads, and a text-based PDF made by a mainstream editor stores real text that standard extraction libraries can read.
So both formats work. But each has specific failure modes worth understanding.
How each format stores your text
- Word (.docx) stores your words as text, paragraph by paragraph, in the order you typed them. A table cell is kept as its own block of text. A parser reading a .docx gets the reading order for free.
- PDF stores characters and their positions on the page. There is no built-in "this cell ends here" or "read this column first". The extractor has to rebuild words, lines and reading order from the positions, which is where layouts with tables and columns go wrong.
What we saw when we compared them
In October 2026 we tested resumes written by ChatGPT and Claude and ran each file through our own scanner. One of them, a resume with a two-column skills table, came out as both a PDF and a Word file from each tool. The tools' own PDFs glued the table cells together, so "Languages" and "Go" became "LanguagesGo", and scored 84 to 85 out of 100. The same content as a Word file scored 99 to 100. Claude's version, pasted into Word and saved with Word's own Save as PDF, scored 99.
That is one resume in our parser, not a vendor's ATS, so treat it as an illustration rather than a ranking. But it matches the mechanism above: the Word file kept each cell separate, and the PDF made by Word was clean too. The PDFs that failed were the ones made by other tools. Our methodology page explains how the scanner scores files.
What 8,220 real resumes showed (October 2026)
The test above is one resume. Since 18 October 2026 our scanner has kept an anonymous record of every file it reads, so we can now compare the two formats on real uploads. Between 18 and 31 October that was 8,220 resumes from 127 countries, test files and bots removed. The full write-up is in what broke in 8,220 resumes.
| PDF (7,151 files) | Word .docx (1,069 files) | |
|---|---|---|
| No reading problems | 32.4% | 51.8% |
| Median score | 95 | 100 |
| Words glued together | 24.1% | 7.8% |
| Missing standard headings | 13.2% | 5.4% |
| No readable text at all | 3.5% | 0.5% |
Where the PDF was made matters too. PDFs saved from Microsoft Word were clean 36.8% of the time, against 31.2% for PDFs from every other app. But Word's own .docx files did better still: they were clean 51.0% of the time. So a PDF from Word is a reasonable choice, and a .docx is the safer one when the portal takes it.
Two caveats. These are people who chose to check their resume, and our scanner is a parser, not a specific employer's system. Some of the glued-words count may also be our reader being strict with certain PDFs, which the October post explains.
Why PDF parsing fails (when it does)
PDFs can have wildly different internal structures even when they look identical. Causes of PDF parsing failure:
1. Image-based PDFs
If your PDF was generated by scanning a printed resume or by "Print to PDF" with image rendering, the file contains an image, not text. The ATS sees nothing.
Test: open your PDF, try to highlight text with cursor. If you can highlight individual words, it's text-based (good). If you can only highlight rectangular regions, it's image-based (bad). The full test and fix, including files whose text layer exists but is converter junk, is in can an ATS read a scanned resume.
2. Custom-encoded fonts
PDFs sometimes embed fonts with custom character encoding, meaning "A" inside the file is encoded as some non-standard byte. The ATS parser sees gibberish even though the rendered PDF looks correct.
This happens most with: design tools (InDesign, Illustrator), unusual fonts, exporting through certain "PDF optimizers."
3. Multi-column reading order
PDFs preserve visual layout, not reading order. A two-column resume in PDF will sometimes read top-to-bottom of column 1, then column 2. Other times it reads left-to-right across columns. Results vary from parser to parser.
4. Text inside paths or images
Some templates use text-as-graphics for headers ("PROFESSIONAL EXPERIENCE" rendered as a vector shape). Looks beautiful, parser-invisible.
How to make your PDF safe (if you must use PDF)
If the application requires PDF (some company portals do), generate it correctly:
- Start from .docx: open Microsoft Word
- File → Save As → PDF (default settings)
- Don't use: "Print to PDF," "Export as Image PDF," or any "PDF optimizer"
- Avoid: design tools (Canva, InDesign, Illustrator) for resume generation. Their PDFs often have parsing issues.
- Test: open the resulting PDF, highlight text with cursor, should highlight word-by-word
The .docx safety checklist
Word is the lower-risk format, but only if the document itself is clean:
- Save as .docx (not .doc, older format, sometimes parses worse)
- If you export .docx from Google Docs or Pages, open it in Word once to check the layout survived
- Use standard fonts (Arial, Calibri, Times New Roman), see font compatibility guide
- Accept all tracked changes and delete comments before saving the final file, so nobody who opens it sees your edits
- Don't password-protect or encrypt the file
What about Apple Pages?
Apple's Pages app can export both .docx and .pdf. The .docx export stores real text, but the layout can differ slightly from what you see in Pages when someone opens it in Word.
Recommendation: if you're a Mac user, install Microsoft Word (free 1-month trial; or Word for Mac; or Office 365 subscription) and use it for final resume export. Pages-exported .docx is "usually fine" but not "always perfect."
What about Google Docs?
Google Docs → Download → .docx produces real text, but watch for a few layout issues:
- Custom Google fonts don't translate to .docx
- Some Google-specific formatting (collapsible headings, comments) may persist
- Tables export with quirks
If you draft in Google Docs, do a final pass in Microsoft Word before submitting.
The right answer for 2026
- Default to .docx when the portal accepts it, because it keeps your reading order
- A text-based PDF from Word's Save As is also fine, and is the right choice when the application asks for PDF
- If using PDF, generate from Word's "Save As → PDF" (default settings)
- Never submit image-based PDFs (scanned printouts)
- Never submit .doc (older format), always .docx
Test before you apply
The fastest way to know if your file format is parsing correctly is to actually run it through a parser. ATS Verification accepts both .docx and .pdf and shows you exactly what was extracted from each. If your name extracts correctly, your dates parse, your work history reconstructs, you're good. If anything's missing, switch formats and try again.
Don't guess. Test.
→ Free ATS scan, try both .docx and .pdf to see which parses better
If your PDF is being refused outright rather than parsed badly, that is a different problem with a different fix: see why your resume PDF will not upload.