Can an ATS read a PDF?

Yes. Every applicant tracking system in mainstream use reads PDFs, and has for years. Workday, Greenhouse, Lever, Taleo, SuccessFactors, iCIMS, Ashby, Naukri’s employer side — all of them parse PDF.

The advice that says otherwise is a decade out of date. It comes from an era when Taleo genuinely handled PDFs badly, and it got repeated long after the systems changed. Sending a Word file to avoid a problem that no longer exists is not a safe default; it is a different set of risks.

What is still true is that some PDFs fail, and when one does it fails silently — the upload succeeds, the confirmation arrives, and the text was never there. So the useful question is not whether PDFs work. It is which ones do not.

The one that is a total failure: an image PDF

If your PDF contains a picture of a page rather than text, there is nothing to extract and the parser gets an empty document. This is not a degradation, it is a zero.

It happens more than people expect:

• Scanning a printed resume.
• Photographing a printout with a phone.
• Exporting from a design tool with an option like “flatten” or “rasterize” turned on.
• “Printing to PDF” from some image viewers and scanner apps.

Some systems run OCR on an image PDF and recover a rough approximation. You cannot rely on it, and OCR output of a two-column layout is frequently scrambled beyond use.

The four that look fine and are not

These are the interesting ones, because the page renders perfectly on screen and the extracted text is wrong. We know these four specifically because our own render pipeline produced every one of them and we have regression tests for each.

1. Bullets built the wrong way scramble the order

A bullet marker made from an absolutely positioned element rather than a real list marker moves that line into a different paint layer — and a PDF stores text in paint order. The result is that every bullet in the document extracts after every job title, so the parser sees a block of employers followed by a block of unattached achievements. On screen it is a normal resume.

2. Some fonts delete characters from the extracted text

A typographic feature that aligns digits to a fixed width can, in some font-and-renderer combinations, cause every digit to vanish from the extracted text while rendering correctly. Your employment dates are visibly on the page and simply absent from what the parser reads. We hit this and it is why we test for it on every build.

A second version of the same problem: a font subset embedded into the PDF can be missing the mapping back to real characters, so extraction returns gibberish or gaps. We removed a shipped typeface over exactly this — it embedded correctly and printed perfectly, and a common PDF reader could not recover several of its digits.

3. Wide letter-spacing splits words into single characters

Push tracking past roughly 0.08em, which is a normal-looking amount for a heading, and the renderer writes each character as its own positioned run. Extraction returns E X P E R I E N C E, and any keyword matching against your section headings misses.

4. Text boxes and layout tables lose their contents

A header band, a sidebar, or a “contact” box in a design tool is often a separate positioned container, and its contents can extract last, out of order, or not at all. The most common casualty is the contact block — the one part of the document the ATS most needs.

Full detail, with the measurements, in what CSS breaks resume parsing and what an ATS reads from your PDF.

Things that are not the problem

• PDF as a format. It is fine, and it is what most employers ask for.
• Having a photo. An image is skipped. The layout used to place it can break things; the picture cannot.
• Two columns, by itself. A column costs you the order the text comes out in, not the text. See are two-column resumes ATS-safe.
• Colour, or a non-default typeface. Neither is read by a parser at all.
• The file name. No modern system scores it. Name it sensibly for the human who opens it and stop there.

How to check your own PDF, in thirty seconds

Open it, select all, copy, paste into a plain text editor. That paste is approximately what the parser receives. Read it and ask three things:

• Is your name, email and phone number at the top?
• Does each job title sit next to its own dates and its own bullets?
• Are the words intact — no gaps, no spaced-out headings?

If nothing pastes, it is an image PDF. If the text is there but scrambled, it is one of the four above. Either way you have learned more in half a minute than any list of “ATS-friendly” rules will tell you, because you are looking at your actual document rather than at general advice.

So should you send PDF or Word?

PDF, unless the posting asks for something else — and if it asks, send what it asks for. The full comparison, including the cases where DOCX genuinely is the better answer, is in PDF vs Word for ATS.

Where this site fits

Our free checker does that copy-paste for you: upload a PDF and it shows the extracted text in full — all of it, not a preview — and grades eight categories against it. No account, and nothing about the file is kept.

If you build here instead, the four failures above are regression tests that run against every template on every change. That is not a marketing claim about being “ATS-optimised”; it is the reason we can name the specific failures at all, since each one is a defect our own pipeline produced before the test existed.