The short answer
Parsing fails silently and in recognisable patterns: missing contact details, jobs assigned to the wrong employer, dates dropped, education merged into experience. Each pattern has a specific cause in the document, and you can see all of them by extracting your own text before you apply.
What matters most
- Parse failures are silent β a damaged record looks like an ordinary weak candidate.
- Most failures fall into five recognisable patterns, each with a specific document cause.
- You can reproduce the extraction step yourself in a couple of minutes.
- Fixing the cause is usually a structural change, not a rewrite of the content.
What a damaged record looks like from the other side
Imagine a recruiter's pipeline view: a table with a name, a current title, a current employer, years of experience and a few skill tags. That summary line is generated from the parsed fields. If your most recent title landed in the employer column, your row reads as gibberish. If your dates were dropped, your years of experience shows as blank while everyone around you shows a number.
Nobody investigates this. There is no reason to; the pipeline has three hundred other rows in it. The record simply looks less appealing than it should, and it is passed over in exactly the way a genuinely weaker candidate would be. That is why this problem deserves more attention than the endless argument about fonts.
The five patterns
| What you see in the extracted text | Cause in your document | Fix |
|---|---|---|
| No email address or phone number anywhere | Contact details placed in the page header or footer, or set as an image | Put them in the first lines of the body, as ordinary text |
| Skills and job bullets interleaved into nonsense | A two-column or sidebar layout whose text order differs from its visual order | Rebuild as a single column; keep two-column treatments only for a short skills list |
| Job titles attached to the wrong employer | Inconsistent line order between entries, or title and employer compressed onto one line | Use an identical line order for every role and give the title its own line |
| Dates missing or a role showing as current | Numeric date formats, dates in a separate aligned column, or an unclear end date | Write the month in words, on the same line as the role, with an explicit end date |
| Education merged into the experience section | A heading the parser did not recognise as a landmark, or a decorative divider instead of a heading | Use conventional heading words, styled as real headings rather than drawn lines |
A sixth failure exists but is not really parsing: an entirely empty extraction, from a document exported with text converted to outlines, or scanned from paper. That is covered in the formatting guide, along with the constructions that cause the first two rows above.
Extraction and interpretation fail differently
It is worth separating the two layers, because the repairs are different. Extraction is mechanical: characters either come out of the file or they do not, and they come out in some order. Interpretation is inferential: having got a stream of text, the software guesses which parts are titles, employers, dates and qualifications.
Extraction problems are caused by containers β text boxes, images, headers, columns, tables used as scaffolding. Interpretation problems are caused by ambiguity β creative headings, compressed lines, inconsistent ordering, unusual date formats, one employer containing three roles. If your plain-text paste looks right but the record is still wrong, the fault is in the second layer, and the answer is almost always to make your structure more boringly repetitive.
Checking yours in fifteen minutes
- 1Export the exact file you would submit
Not the working document β the final PDF or Word file, from the tool you actually use, with the settings you actually use. Export options change what ends up in the text layer.
- 2Select all, copy, paste into plain text
Any notepad application with no formatting. This approximates the extraction step, and it is the fastest way to find missing or scrambled content.
- 3Read the result as a stranger
Is your name first? Is your email present? Does each job sit with its own dates? Does anything appear twice, or in the wrong place? Mark every oddity.
- 4Run it through a parser
Our free ATS checker shows the text it extracts and which terms from a posting are absent. Paste a real posting alongside it β the gap list is more useful than any score.
- 5Use an employer autofill as a second opinion
Where an application form offers to fill itself from your resume, do it and read the result carefully before submitting. That is a real production parser showing you its output for free.
- 6Fix causes, not symptoms
If dates vanished, change the date format everywhere rather than adding them again in a new place. Then re-export and repeat the test from step one.
The autofill trick, in more detail
The step above deserves emphasis because it is the only way to see a genuine commercial parser's interpretation of your document without applying for anything. Many application forms offer to populate name, contact details, employment history and education from an uploaded file. What appears in those boxes is the record.
- Check the employment rows. Right employer against right title, right dates, right order. This is where most damage shows.
- Check the end dates. A role that ended two years ago showing as current is a common and quietly damaging error.
- Check education. Institution, qualification and year should be in the correct three fields, not one string in the wrong box.
- Check what is empty. Blank fields tell you what your document failed to make findable.
- Correct the form before you submit. Whatever you do to your document afterwards, the application in front of you should go in accurate.
When the record is right and you still hear nothing
Parsing is a floor, not a ceiling. A perfectly extracted record for a role you are not a credible candidate for is still a rejection, and a great deal of hiring silence has nothing to do with software at all β requisitions get paused, filled internally, or reprioritised, and candidate-facing statuses rarely say so.
It is also worth checking your assumptions about the document itself against a source with nothing to sell you: the Purdue OWL resume writing section covers the conventional structure parsers are built around, and where a process publishes its own requirements β as the USAJOBS resume builder does β those instructions replace every general rule on this page.
So spend the effort once. Fix the structure of your document, confirm the extraction is clean, and then stop thinking about parsing entirely and put the time into aiming applications and writing evidence. If you want a person rather than a parser to tell you where the document is weak, our free resume review reads it the way a hiring manager would, and the builder produces documents that pass the extraction tests above without any of this being your problem.
One caveat about scores
Any tool, ours included, that gives your resume a number is producing an estimate against one interpretation of one posting. It is a useful prompt and a terrible target. Chasing a higher number by inserting terms you cannot defend converts a document a person might like into one an interviewer will dismantle. Read the gap list, act on the true parts, and ignore the score.
Questions people actually ask
How do I know if my resume was parsed incorrectly?
You will not be told, so you have to check yourself. Copy the text out of your exported file and paste it into a plain text editor: that approximates what a parser extracts. For interpretation, upload the file to an application form that offers autofill and read what lands in each field. Those two checks catch nearly everything.
Does a parsing error mean automatic rejection?
No. It means your record is less complete or less accurate than it should be, so you look weaker in a list and you are less likely to be returned by a search. Nobody rejects you for it; you simply do not surface. That is worse in practice, because there is no signal telling you to fix anything.
Why did my two-page resume only parse the first page?
That usually points to something structural on the page break β a table or text box spanning the boundary, or a second page built inside a different container. Rebuild the second page in the same simple structure as the first and re-test. Page count itself is not the cause.
My name came out as my employer. What causes that?
Almost always a header design where your name is styled the same as, or positioned near, other text at the top of the page. Give your name its own line at the very top of the body, larger than everything else, with contact details on the line below.
Do these problems affect Word files as well as PDFs?
Yes, though differently. Word documents suffer more from text boxes, content controls and table scaffolding, while PDFs suffer more from lost text layers and unusual reading order. The plain-text copy test works on both, which is why it is the check worth doing regardless of format.
