Ten files, five controlled layout conditions.
| Fixture | DOCX extraction | PDF extraction | Observed difference |
|---|---|---|---|
| Simple single column | 15/15 facts; order preserved | 15/15 facts; order preserved | No meaningful winner in this extraction test. |
| Two columns | 15/15 facts; section order changed | 15/15 facts; section order changed | Both emitted the left column before the right column. |
| Contact details in header | 13/15; email and phone omitted | 15/15 facts; order preserved | Mammoth omitted the DOCX header; PDF.js read the exported text layer. |
| Table-based work history | 15/15; title/employer text joined | 15/15 facts; order preserved | Presence survived, but DOCX spacing was less reliable. |
| Image-only scan | 0/15; no text layer | 0/15; no text layer | Neither local parser performs OCR. |
PDF was better only in the header-contact condition. It did not repair two-column reading order or create a text layer for a scan. DOCX was not safer merely because it was editable. The exact file structure determined the result.
Method and scoring.
We created one synthetic resume with a fictional candidate, two jobs, education, skills, email, and phone. We then placed the same content into five layouts: plain single column, two columns, header contact details, table-based employment history, and an image-only scan. Each DOCX was exported to PDF through the same LibreOffice rendering path.
On 18 September 2026 we extracted DOCX text with Mammoth 1.12.x and PDF text with PDF.js 5.4.394, the libraries used by Jobsistant's browser checker. We checked 15 fixed facts, the order of Summary → Experience → Education → Skills, and the order of title → employer → date for both jobs.
- Fact recovered means the expected string appeared in extracted text.
- Order preserved means the fixed sequence appeared in the intended order.
- The test did not score design quality, qualifications, keyword relevance, or ATS database-field mapping.
What job seekers should do with the result.
- Follow the posting. A required file type overrides generic advice.
- Keep critical contact text in the document body. Headers are a known extraction boundary.
- Avoid using columns for the resume's main reading sequence. Every word may survive while the semantic order still changes.
- Do not submit an image-only scan. Visible words are not necessarily machine-readable words.
- Test the exported file. A clean source document can produce a different PDF text layer depending on the exporter.
USAJOBS currently recommends PDF to preserve formatting and page count while also accepting DOCX. That is platform-specific submission guidance, not evidence that PDF wins on every parser. See the official USAJOBS resume-upload guidance.
Download and reproduce the test.
The files below are synthetic and contain no real person's information. Run them through another parser, record its version and date, and compare the same 15 facts rather than a proprietary score.
| Condition | DOCX | |
|---|---|---|
| Single column | Download DOCX | Download PDF |
| Two column | Download DOCX | Download PDF |
| Header contact | Download DOCX | Download PDF |
| Table work history | Download DOCX | Download PDF |
| Image-only scan | Download DOCX | Download PDF |
The generation and measurement scripts are kept with the site source so the test can be rerun after parser upgrades.
Limitations.
- Five synthetic conditions and one content set cannot represent every resume.
- This measures Jobsistant's local extraction libraries, not Workday, iCIMS, Greenhouse, Lever, Taleo, or another proprietary parser.
- Recovering text does not prove that an ATS mapped a title, employer, or date into the correct database field.
- Another Word version, PDF exporter, font, language, or layout can produce different output.
- We did not apply OCR. Systems with OCR may recover some scanned text, with their own error modes.
The narrow conclusion is still useful: file extension alone is not an ATS-readability strategy. Test the exact file and keep the semantic structure simple.