Neither PDF nor Word is the safer resume format. A PDF resume can lose text outright, and a Word resume can send your contact details to the wrong place in the extracted output. You cannot see either failure on the page in front of you.
A PDF stores drawing instructions, not characters. If the font it embeds doesn’t carry a way to map those instructions back to text, the extractor either guesses wrong or drops the character, and which of the two happens depends on the kind of font.
A Word file stores its text as text, so that failure doesn’t apply to it. What goes wrong instead is placement. A header or footer holds real text that the parser writes out somewhere else in the extracted document, ahead of your name or after your last job.
Both are avoidable. Changing format doesn’t fix either one.
Is a PDF resume safe to send?
Yes, when the PDF carries a way to map its characters back to text. The format doesn’t require it to carry one.
We downloaded the published PDF specification, ISO 32000, from Adobe and read section 9.10.2. The ToUnicode entry is marked optional in every font dictionary table that carries it: “(Optional; PDF 1.2)” for the simple Type 1 and Type 3 fonts, and “(Optional)” for the composite Type 0 font that matters here.
Section 9.10.2 gives three methods, “in the priority given,” for turning a character code back into Unicode. The first is a ToUnicode CMap. The second, for a simple font using MacRomanEncoding, MacExpertEncoding or WinAnsiEncoding, is a lookup through the Adobe Glyph List. The third, for a composite font, is one of the spec’s predefined CMaps (excluding Identity-H and Identity-V) or a descendant CIDFont in the Adobe-GB1, Adobe-CNS1, Adobe-Japan1 or Adobe-Korea1 collections.
A subset-embedded Identity-H CIDFontType2 font is composite, so the simple-font method can’t reach it, and the composite method excludes Identity-H by name. If its descendant isn’t in one of those four Adobe collections either, and no ToUnicode entry was written, it matches none of the three. The spec says so itself: “If these methods fail to produce a Unicode value, there is no way to determine what the character code represents in which case a conforming reader may choose a character code of their choosing.”
We read PDFBox’s font classes next, and found a path the spec doesn’t have. PDType0Font.toUnicode falls back to a reverse lookup through the embedded TrueType font’s own character map, and PDCIDFontType2 holds that lookup in a field its own source comments “may be null.” Whether a given subsetter kept that map is something we didn’t measure.
Why does text go missing from a resume PDF?
Because when a PDF cannot map a character back to text, some fonts have that character skipped entirely rather than guessed at. Which of the two happens depends on the kind of font, not on the resume.
We read the glyph-handling branch in PDFBox’s LegacyPDFStreamEngine. When font.toUnicode returns nothing, a simple font has its raw character code coerced into a character, which is where garbled text, the familiar gibberish, comes from. A composite font gets no such fallback. The method returns without emitting anything at all. The comment at that branch says why: “Acrobat doesn’t seem to coerce composite font’s character codes, instead it skips them.”
The two branches produce two different failures. For a simple font, the character survives, wrong. For a composite font, which is what a subset-embedded Identity-H CIDFontType2 is, the character doesn’t survive at all. Nothing in the extracted output marks the gap.
Which branch you hit depends on how your export tool embedded the font.
Does copying the text out of your resume PDF prove it will parse?
Only partly. Copying the text out of a PDF tells you whether the character-to-Unicode mapping failed in the viewer you copied from, and nothing else.
Selecting text and pasting it runs through the same character-to-Unicode mapping the extractor needs. Missing characters or nonsense in the paste mean the mapping failed. A clean paste means it didn’t, in that viewer.
The paste doesn’t test the order the text comes out in. That’s a different mechanism, the one a two-column layout turns on, and we wrote it up separately. It also tells you nothing about a Word file, which doesn’t have this failure at all.
Viewers differ in which fallback paths they implement, so a clean paste in one doesn’t guarantee a clean parse in another. Scope the result to where you tested it.
Is a Word resume worse than a PDF resume?
No. Sending Word trades the PDF failure for a different one.
A DOCX file stores its text as text, not as drawing instructions, so the character-mapping failure above has no equivalent there. Its failure is about where text lands. A piece of your resume comes out somewhere else in the extracted output than where it sits on the page.
Why do contact details in a Word header get separated from your name?
Apache Tika writes a document-level header out before the body of a DOCX, and a footer after it. A phone number in a header arrives ahead of everything on the page. One in a footer arrives after the last line of the last job.
We read both of Tika’s DOCX extractors, and both place a document-level header and footer that way. The classic DOM-based extractor, XWPFWordExtractorDecorator, calls extractHeaders before extractIBodyText and extractFooters after it, inside buildXHTML. The streaming SXWPFWordExtractorDecorator handles headers in its own step before it processes the main document part, and reaches footers only in the trailing loop its own source comment says is there to “just dump other components at end.” Both are gated on includeHeadersAndFooters, which OfficeParserConfig defaults to true.
The text is still there. It’s written to a different position in the extracted output than the position it holds on the printed page.
Does a Word header on every page protect your contact details?
No. A header that repeats on every page is something page rendering does. There’s one header part in the file, and it gets written out once.
A comment added to the streaming extractor on Tika’s development branch says why that isn’t a problem for text extraction, even though it looks wrong against the printed page: it takes headers and footers “at the document level, which is fine for text extraction since OOXML is flow-based, not page-based.”
The two extractors genuinely differ in one place. The DOM-based extractor also writes a section’s own header and footer inline, mid-body, around any paragraph whose sectPr marks a section break. The streaming extractor has no sectPr handling at all, and a comment on Tika’s development branch spells the difference out. Where a document has only a single, document-level header and no section breaks, both extractors place the header and the footer the same way.
Does the program you made your resume in change how the text comes out?
Yes for the PDF failure, no for the Word failure.
The PDF failure turns on how a font was embedded and whether its subsetter kept a character map, and the export tool decides both, not you. All three of the spec’s methods, plus the TrueType character-map fallback PDFBox adds on top of them, depend on the font. Which programs leave that map out is the part we didn’t measure.
The Word failure turns on where you typed a phone number. Putting it in the header or footer instead of the body is something you did, in whichever program you used.
The paint-order question behind two-column layouts has the same shape. It turns on a property of the tool that built the file, and nothing on the page shows you which way it went.
What we read, and what we did not test
We read the published source of Apache Tika and Apache PDFBox, and the published PDF specification, ISO 32000. We did not test any of this against Workday, Greenhouse or Lever. Of the vendor sandboxes we checked, every one sits behind a paid tier or a partner agreement, so no live ATS was reachable from here.
Tika ships two DOCX extractors, and they aren’t interchangeable defaults, so we read both at their released tags and on the development branch. In the released 3.x line, the classic DOM extractor runs by default. The streaming one is opt-in, behind a setting whose own documentation calls it “experimental.” On the 4.0.0-SNAPSHOT development branch, the DOM extractor is gone and the streaming one runs for every DOCX. The header-and-footer behaviour this article rests on is the same in both, which is the only reason the claim survives the difference. We’re not picking one and calling it universal.
Which resume format should you send?
Send whichever format the posting asks for. What removes both failures is keeping contact details in the document body instead of a header or footer, and exporting from a tool whose PDF output you can check yourself, by selecting the text and pasting it somewhere plain.
We read our own PDF builder to confirm what it emits. It has no header or footer region at all, so on a resume exported from HoneCV the contact details are in the body by construction.