The short answer: a text-based PDF is the best default, a clean DOCX is a close second, and the real danger isn't the extension — it's how the file was made. Here's what actually happens to each format inside a parser.
Can an ATS read a PDF at all?
Yes. This is the most persistent myth in resume advice, and it's about a decade out of date. Every mainstream applicant tracking system reads text-based PDFs. The advice to avoid PDFs comes from an era of much weaker extraction, and it has outlived the problem it described.
What hasn't changed is the failure case underneath the myth: a PDF that contains no text. If your resume was exported as an image, scanned from paper, or produced by a design tool that converted your letters into vector shapes, then there is nothing for a parser to extract, and you will look like a blank application.
How each format gets read
Text runs pinned to coordinates. Reading order is reconstructed — layout is frozen forever.
PDF — a drawn page
<document>
<body>
<p>Experience…</p>
<list>bullets…</list>
</body>
<header>phone, email</header>
<textbox>skills</textbox>
A real document tree — but headers and text boxes live outside the body, where many parsers never look.
DOCX — an XML tree
A PDF is a page-drawing format. The parser doesn't read paragraphs; it reads positioned text runs and reconstructs reading order from coordinates. That works beautifully when the PDF came from Word, Google Docs, or LaTeX — and fails when it came from a design tool that exported your text as curves or a flattened image.
A DOCX is a zip file of XML. The parser reads the document tree directly — real paragraphs, real lists. That's more structure to work with, but also more places to hide content: text boxes, headers, footers, and shapes live outside the main body tree, and many parsers never look there.
Failure modes by format
| Failure | DOCX | |
|---|---|---|
| Text exported as image (Canva-style) | Parses as empty | Rare |
| Contact info in header/footer | Usually survives | Often skipped |
| Text boxes / floating shapes | Usually survives | Frequently skipped |
| Layout reflow changing line order | No — layout is frozen | Possible across Word versions |
| Fancy template styling lost | No | Sometimes |
| Ligature/encoding garbage (fi → junk) | Possible with exotic fonts | Rare |
Two takeaways from that table. First, the PDF column's problems are all creation-time problems — export from a text-first editor and they vanish. Second, the DOCX column's problems are all invisible — the file looks fine in Word while the parser silently drops your header.
Exporting safely, by tool
| Tool | Do this | Watch out for |
|---|---|---|
| Microsoft Word | File → Save As → PDF | "Print to PDF" on some setups rasterizes; use Save As |
| Google Docs | File → Download → PDF Document | Downloading as "Web Page" or image formats |
| Apple Pages | File → Export To → PDF | Exporting to "Images"; templates using floating text boxes |
| LaTeX / Overleaf | Standard PDF output is fine | Exotic font packages producing broken ligature encoding |
| Canva / Figma / Illustrator | Export PDF with text preserved, then run the select-text test | Default exports frequently outline or flatten text |
| Browser "Print → Save as PDF" | Avoid for resumes | Can rasterize, and adds headers/footers and URLs |
The pattern is consistent: tools built around text produce parseable PDFs by default, and tools built around graphics don't. If you love a Canva template, keep it — just verify the export, every single time you re-export.
What about other formats?
- .txt — parses perfectly and looks like nothing. Only send it if asked.
- .rtf — widely readable but antiquated; no reason to choose it over PDF.
- .pages / .odt — many portals reject them outright. Convert first.
- A link to an online resume — never as the only submission. Some portals strip links, and no parser will follow one.
- Images (.png / .jpg) — the worst possible choice; zero extractable text.
Does the file name matter?
Not to the parser, which ignores it entirely. It matters to the human who ends
up with forty files in a folder. Use Firstname-Lastname-Role.pdf. Avoid
resume_final_v7_USE THIS ONE.pdf, avoid spaces if you can, and never leave a
previous employer's name in the file name — it happens more than you'd think.
The decision rule
- 1
The portal asks for a specific format? Send exactly that.
The employer knows what their own system parses best — this overrides every other rule.
- 2
No preference stated? Send PDF from Word or Google Docs.
Never print-to-PDF from a browser, and never a design-tool export — both can destroy the text layer.
- 3
Recruiter emailing your resume around? Use DOCX.
It travels better through the editing and re-saving workflows agencies actually use.
See the full layout rules in the ATS-friendly resume format, and the parsing pipeline these failures happen inside in how an ATS actually reads your resume.
Test the actual file, not the theory
The free MeritSlate checker parses your real upload the way the vendor systems do and shows you the extracted result — if your phone number, dates, or skills didn't survive the trip, you'll see it before a recruiter doesn't.
Frequently asked questions
- Can applicant tracking systems read PDFs?
- Yes — every mainstream ATS reads text-based PDFs fine. The failures come from PDFs exported as images (scans, screenshots, some design tools), which contain no selectable text at all. If you can't select and copy the text in your own PDF, no parser can read it either.
- Should I submit a PDF or a Word document?
- PDF for almost every online application: it preserves your layout and parses reliably. Choose DOCX when the posting explicitly asks for it, or when a recruiter needs to edit your resume before sending it on — which agencies routinely do.
Written by
MeritSlate Team
The team building MeritSlate's deterministic scoring engine — nine evidence-anchored axes, a nine-vendor ATS parse simulation, and every point backed by receipts.