Read What the Parser Read Before Blaming Your File Format

Test Your Own File in Thirty Seconds

Open the exact file you plan to submit, select all the text, and paste it into a blank plain-text document, or use your word processor's own "save as plain text" option. What comes out is close to what a parser sees: no columns, no boxes, no font, just a sequence of lines. Read that sequence from the top.

Check four things in order. Does your name and contact information appear near the top rather than scattered or missing? Do your job titles and employer names stay attached to the right dates, rather than all the dates bunching together separately from all the titles? Do your section headings (Experience, Education, Skills) appear as recognizable words rather than vanishing entirely? Is the reading order roughly the order you intended, top to bottom, rather than column one's contents mixed into column two's?

If all four hold, your file format is not the problem, and it is worth looking at what you wrote rather than how you formatted it. Layout is the variable the vendors themselves name: Workday's administrator documentation states that parsing results "can vary based on resume format and order of words" and that, for best results, resumes should not contain images or image-based styles ¹. It names no file type at all, which is the first sign that the argument you have been reading is about something else.

What Actually Breaks a Parser

Greenhouse publishes a named list of what makes a resume fail to parse in its own system, and not one line of it names PDF or Word: a file over 2.5MB, graphics or word art, a resume uploaded as an image rather than a document, tables, headers or footers, contact information placed inside a header, footer or text box, and a columned layout ².

The columns are worth explaining, because they cause the strangest-looking failures. A parser generally reads a page as a single stream of text, left to right, top to bottom. A two-column layout gets read one row at a time across both columns, so a line from your left-hand summary can land directly in the middle of your right-hand job description, and the result is a garbled record even though the file opened perfectly on your own screen. That is exactly the failure the thirty-second test above catches, and it is invisible if you only ever look at the formatted page rather than the extracted text.

A dated icon instead of written text, a skills section built as a graphic bar chart, and a name set as a logo-style image are the same failure in different disguises: information that is visually obvious to you and invisible to whatever reads the file next. Two entries on the same Greenhouse list are about wording rather than layout, a company name given without an Inc. or LLC and a job title cut down to "Sr. Account Exec" instead of written out, so structure is most of what breaks a parse rather than all of it ². Greenhouse's stated consequence for a failed parse is that the resume stays attached to the candidate and a person enters the fields by hand ². The documented cost is a slower, more manual read. The page puts no figure on how often a parse fails and offers no evidence either way about whether it changes a hiring outcome, so a clean file is worth having without being the explanation for a rejection.

Fix the Structure Instead of Guessing at File Type

PDF versus Word does not settle this on its own. What matters is whether the file carries selectable, structured text, and both formats can do that or fail at it depending on how the document was built. A PDF exported from a plain, single-column word-processing document usually carries clean text. A PDF that started life as a scanned image or a heavily designed graphic layout usually does not, regardless of the file extension on it.

The more useful habit than picking a side in that argument is doing what a government hiring system already tells its own applicants to do: read the employer's stated file rules and follow those exactly, rather than guessing at a universal one. USAJOBS, the federal government's own hiring system, states on its 2026 help pages that it accepts PDF, DOC, DOCX and several other formats, recommends PDF "to maintain formatting," and caps the file at 5MB ³. Those rules bind US federal applications and nothing else. When an employer names a format, that instruction beats any general rule circulating online, including the ones in this article.

Once you know what actually failed, the repair is usually smaller than the anxiety around it. Rebuild the document as a single column, with your name and contact details as plain text at the top rather than inside a header, real text headings for each section, and no tables, text boxes or graphics standing in for content. None of that requires new software or a paid template; it is a set of choices inside whichever word processor you already have open, and most of them take only a few minutes once you know which ones to look for. The two changes that fix the most, in order: move anything sitting in a header or footer into the body of the page, and replace any multi-column block with a single vertical one. How a template's layout choices carry into this same risk is worth reading once, so the next resume you build starts from a structure that does not need fixing.

What is not worth doing is chasing a rumor about a specific font, a specific margin, or a specific export setting that supposedly "beats" a parser. Neither Workday nor Greenhouse names one anywhere in the pages above, and where a hiring system does list fonts and margins, as USAJOBS does, it lists them as recommendations rather than parsing requirements. Most employers screening resumes today are working from the same underlying problem the ATS keyword filter has been wrestling with: what a filter is even supposed to catch once writing to the posting's language costs almost nothing is a live question on their side of the process, and what an ATS actually does with the record once it parses has nothing to do with which font drew the letters.

See a sample report >