How ATS resume parsing actually works (and what breaks it)

Most advice about applicant tracking systems (ATS) is folklore: "the robot rejects 75% of resumes", "use white text keywords", "never use columns". As engineers we can do better than folklore. An ATS is a piece of software with a pipeline, and once you know the pipeline, the failure modes become predictable.

The pipeline, simplified

Most ATS products (Greenhouse, Lever, Workday, Taleo and others) do roughly the same thing when you upload a file:

1. Extract text from the PDF or DOCX.
2. Segment the text into sections (experience, education, skills).
3. Extract entities: name, email, phone, employers, job titles, dates, skills.
4. Store those fields in a candidate record.
5. Surface the record to a recruiter, who searches or filters, or just reads it.

Notice what is not in that list: an AI judge silently scoring you out of the pool. In most companies, a human recruiter looks at the parsed profile or the original file. Automated rejection is usually limited to explicit knockout questions ("Do you have the right to work in X?"). The parser's real job is to make your data searchable. When parsing fails, you don't get rejected by a robot; you become unfindable and hard to read.

Step 1: text extraction is where layouts die

A PDF doesn't store "paragraphs". It stores glyphs positioned at coordinates. The extractor has to reconstruct reading order from geometry. That is why layout choices matter:

• Multi-column layouts can be read straight across rows, so a left-column skill list and a right-column job description get interleaved into nonsense.
• Text in tables is often flattened cell by cell in an unexpected order.
• Text boxes, headers and footers may be skipped entirely. Putting your phone number and email in the page header is a classic way to end up with a candidate record that has no contact details.
• Icons instead of labels (a little envelope glyph rather than the word "Email") give the parser nothing to anchor on.
• Scanned or image-based PDFs contain no text at all unless the system runs OCR, which is error-prone.

A quick test you can run yourself: open your PDF, select all, copy, and paste into a plain text editor. What you see is roughly what the parser sees. If the order is scrambled or something is missing, fix the layout, not the wording.

Step 2: section segmentation uses headings as anchors

Parsers look for recognizable headings to decide where "experience" ends and "education" begins. "Work Experience", "Experience", "Education", "Skills" all work. "My Journey" or "Where I've Been" does not. Creative headings are a gamble with no upside.

Dates matter here as well. Consistent formats (Mar 2022 – Present) let the parser build a timeline and compute years of experience. Mixing 03/22, Spring 2022 and '22-now makes that computation unreliable.

Step 3: entity extraction is statistical, not magical

Name, employer and job title extraction typically combines rules, dictionaries and some ML. Practical consequences:

• Put each role on a predictable line: Title, Company, Dates. Don't bury the employer inside a paragraph.
• Use standard job titles where they're accurate. If your internal title was "Code Wizard II", add the conventional equivalent in parentheses.
• Spell out acronyms at least once: "Continuous Integration (CI)", "Amazon Web Services (AWS)". Recruiters search for both forms.

Step 5: search is mostly keyword matching

Once your data is in the system, a recruiter typically searches it with boolean or keyword queries like "React" AND "TypeScript" AND "GraphQL". This is where the job description's vocabulary matters. If the posting says "Kubernetes" and your resume says "container orchestration" only, a literal search won't find you.

The right takeaway is not keyword stuffing. Stuffed lists read badly to the human who opens your profile next, and modern systems often show the matched context. The right takeaway is to use the same name for a technology you actually used, in a bullet that shows what you did with it:

Before: "Worked on deployment infrastructure."
After: "Migrated 14 services from VMs to Kubernetes, cutting deploy time from 40 to 6 minutes."

The second version contains the searchable term, a number, and a result.

What does not help

• White-text keyword hiding. Copying to plain text exposes it, and some systems flag it. A human who sees it will not be charmed.
• Fancy templates with graphics. Skill-level bars ("JavaScript: 4/5") are not parseable and say nothing meaningful anyway.
• Unusual file formats. Stick to PDF (text-based, exported from a real editor) or DOCX unless the posting says otherwise.

A practical checklist

1. Single column, standard fonts, no text boxes.
2. Contact details in the body, not the header.
3. Conventional headings: Experience, Education, Skills.
4. Consistent date format and one role per clearly delimited block.
5. Job-description vocabulary used honestly, inside achievement bullets.
6. Copy-paste test into a plain text editor before you send.

If you want a second opinion without building your own extraction test, a tool like NextCV's CV check can flag structural and readability problems in a CV. But the checklist above gets you most of the way with nothing but a text editor.

Wrap-up

An ATS is a parser plus a search index. Make your resume easy to parse (clean layout, standard headings, consistent dates) and easy to find (the real vocabulary of the role, backed by concrete results). Then remember that the final reader is a person, so write for them first.