The short version

  • No major ATS says it prefers DOCX. The only one that states a preference is Greenhouse, and it says upload a PDF for best results.
  • Greenhouse, Workday, Taleo and iCIMS all accept both. Format is not the gate people think it is.
  • The one real warning against PDF comes from a parser vendor, and its stated reason is corrupt files, not the format itself.
  • A scanned PDF is a different thing entirely. It carries no text layer and needs OCR, which parser vendors sell as a paid add-on.
  • The tightest documented limit anywhere is Taleo's 1 MB default per attachment, roughly a hundredth of Greenhouse's cap. Under 1 MB is the only size advice that survives every system.

Ask the internet which file format to send and you get one answer, delivered with total confidence: always DOCX, because PDFs parse badly. It is one of the most repeated rules in job searching.

It is also unsupported. Read the vendor documentation and not one major applicant tracking system asks for Word, while the only one that expresses a preference asks for the opposite. What the docs do describe is a set of failure modes that have nothing to do with choosing between two extensions.

What the vendors actually accept

Greenhouse accepts .doc, .docx, .pdf, .rtf and .txt. Workday's HiredScore documentation lists DOC, DOCX, PDF, RTF and TXT. Oracle's Taleo permits a long list including PDF and Word. iCIMS extracts text from an even longer one.

Then Greenhouse goes further and tells candidates directly: upload a PDF for best results, and if an upload fails, re-save as PDF and reduce the file size. That is a named tier-one vendor advising the exact opposite of the folklore.

The one real argument against PDF

There is a genuine warning in the documentation, and it is worth taking seriously because it comes from the layer that does the actual extraction. Textkernel, whose parser lineage sits behind a number of these systems, has a section in its developer docs headed "Documents That Can Cause Problems" that says plainly: if you want to minimise conversion problems, do not use PDF documents.

Read the reason and it stops supporting the folklore. Textkernel says many PDFs parse fine, and that most of its "this document did not parse correctly" bug reports come down to the document being a corrupt PDF file. The problem it describes is malformed files, not the format.

Worth noting the same vendor's supported formats page lists PDF first among more than seventy document types, with no accuracy caveat attached. The guidance is not reconciled across their own documentation, which is a reasonable clue about how much weight the format question deserves.

Core Principle
“The failure mode is bad PDFs, not PDFs. Those are different problems with different fixes.”

Scanned PDFs are a different file entirely

The distinction that actually matters is not PDF against Word. It is whether your file contains real text at all. A PDF exported from Word or Google Docs carries a text layer that a parser reads directly. A scan or a photograph carries an image of text, and nothing can read it without optical character recognition first.

Parser vendors treat these as separate categories rather than variations. Textkernel's format list files ordinary PDF under document formats and points scanned PDFs to a separate image formats section, which is an optional paid OCR add-on, noting that images take considerably longer to parse because OCR is computationally expensive. Workday's parsing guidance says simply to use resumes without images or image-based styles.

So the rule worth remembering is narrow and absolute: export from your editor, never scan or screenshot. That single choice matters more than every DOCX-versus-PDF argument combined.

Recommended Action

See what a parser extracts from your file

Optimize your application materials in under 2 minutes.

Try it now

Running your own file through extraction is the only way to know whether the text came out in the right order, which is the question format arguments are a poor proxy for.

Why a PDF can look right and extract wrong

There is a technical reason multi-column resumes scramble, and it is not folklore. The W3C's PDF technology notes explain that a PDF's logical structure is stored separately from its visible content, which allows the ordering and nesting of logical elements to be entirely independent of the order and location of the graphics objects drawn on the page.

In plain terms: how a PDF looks and the order its text is stored in are two different things, and they are allowed to disagree. That is why a resume can be perfectly legible to you and arrive at the other end with a job title separated from its dates. Layout is what decides this, and it is a stronger predictor of a clean parse than which extension you picked.

The constraints that actually fail uploads

These are documented, specific, and almost entirely absent from the usual advice.

  • Size. Taleo defaults to 1 MB per attached file and lets an employer raise that to no more than 5 MB per file, while Greenhouse allows 100 MB. Staying under 1 MB is the only size rule that clears every system.
  • Macros. Taleo blocks and disables macros in uploaded files, which makes .docm and .dotm a real hazard. This is a risk on the Word side that the pro-DOCX advice never mentions.
  • Timeouts. iCIMS gives up on text extraction after one minute thirty seconds, with two attempts. A heavy file can simply time out.
  • Unreadable characters. Greenhouse attributes failed imports to files with too little information, non-standard types, or characters its parser does not recognise, which is what decorative icon fonts produce.
  • Linked images. Greenhouse notes externally linked images are not loaded when a file is converted for preview, while embedded ones are preserved.

Two things commonly asserted are not documented anywhere we could verify: rules about filenames, and behaviour with password-protected files. Naming your file FirstName_LastName.pdf is a sensible courtesy to the human downloading it, not a system requirement. If a vendor documents either, we have not found it.

So which should you send?

Send a PDF exported from your editor, unless the application form asks for something else, in which case send what it asks for. Keep it under a megabyte, keep the layout single-column, and never upload a scan. Before you send it, run the final file through an ATS resume checker to confirm the text comes out in the right order.

If you want a second copy in Word for the recruiters who still ask for one, keep it as .docx rather than a macro-enabled variant. Beyond that, the format question does not deserve the attention it gets, and the hours spent on it are better spent on what the bullets actually say.

Frequently asked questions

Send a PDF exported from your editor, unless the application form asks for something else, in which case send what it asks for. Keep it under a megabyte, keep the layout single-column, and never upload a scan.

None that documents a preference. Greenhouse, Workday, Taleo and iCIMS all accept both. The only vendor that states a preference is Greenhouse, and it tells candidates to upload a PDF for best results, and to re-save as PDF and reduce the file size if an upload fails.

It does, and the reason matters. Its developer docs have a section headed "Documents That Can Cause Problems" advising against PDF, but the stated cause is that most "this document did not parse correctly" bug reports come down to a corrupt PDF file. That is malformed files, not the format. The same vendor's supported formats page lists PDF first among more than seventy document types with no accuracy caveat attached.

Because how a PDF looks and the order its text is stored in are two different things. The W3C's PDF technology notes explain that a PDF's logical structure is stored separately from its visible content, so the ordering of logical elements can be entirely independent of the graphics drawn on the page. That is how a resume legible to you arrives with a job title separated from its dates. Layout decides this, and it predicts a clean parse far better than the extension does.

No. A scan carries an image of text rather than a text layer, and nothing reads it without optical character recognition first. Parser vendors treat these as separate categories: Textkernel points scanned PDFs to an optional paid OCR add-on, noting images take considerably longer to parse. Export from your editor instead. That single choice matters more than every DOCX-versus-PDF argument combined.

Under 1 MB is the only rule that clears every system. Taleo defaults to 1 MB per attached file, roughly a hundredth of Greenhouse's 100 MB cap, and even a raised Taleo limit cannot exceed 5 MB per file. iCIMS also gives up on text extraction after one minute thirty seconds across two attempts, so a heavy file can simply time out.

Not as a system requirement, as far as any vendor documents. Naming your file FirstName_LastName.pdf is a sensible courtesy to the human downloading it. The same goes for claims about password-protected files: commonly asserted, not documented anywhere we could verify.

Yes, and the pro-DOCX advice never mentions them. Taleo blocks and disables macros in uploaded files, which makes .docm and .dotm a real hazard, so keep any Word copy as plain .docx. Greenhouse also attributes failed imports to characters its parser does not recognise, which is what decorative icon fonts produce.