How Modern ATS Parsers Actually Work (Workday, Greenhouse, Lever, Taleo Compared)

The phrase "ATS-friendly resume" gets used so loosely on the internet that it's almost meaningless. Half the advice you'll find is from 2014, when ATS systems literally couldn't read tables. The other half conflates "the ATS rejected me" with "I never heard back from the recruiter" — which are usually different things.

This post is the version that would be technically defensible if a recruiter, an ATS vendor's engineer, and the developer of an LLM-augmented parser were all in the room. Updated for 2026, where most major ATS vendors have shipped LLM-powered scoring layers on top of their classical parsers.

What an ATS actually does

Applicant Tracking Systems are not, by default, "rejection machines." They're database tools for recruiters: track candidates, store resumes, route applications, schedule interviews, and keep a record for compliance. The "rejection" part is a configuration choice by the company using the ATS — and modern recruiting teams are increasingly turning automated rejection off because they don't trust the keyword filters.

A typical lifecycle of a 2026 application:

1. Upload. You submit a PDF (rarely DOCX, almost never .txt).
2. Parse. The ATS extracts plain text + structure (sections, dates, employers, titles).
3. Index. The plain text gets indexed in a search database so recruiters can run queries.
4. Score (sometimes). A scoring layer — keyword match, semantic match, or an LLM judge — produces a number or band for ranked review.
5. Route. Application is shown to the recruiter, often with the score visible.
6. Recruiter reviews. Human reads the top of the ranked list, often skipping the bottom entirely.

Steps 2-5 are where "ATS-friendly" actually matters. Most of what your resume gets judged on at this stage is parseability + match score, not literal keyword presence.

Step 1: Parsing (where 90% of the urban myths come from)

Every major ATS vendor (Greenhouse, Workday, Lever, iCIMS, Ashby, Rippling Talent, Taleo, SuccessFactors, Bullhorn) ships a resume parser. The job of the parser is to turn your PDF/DOCX into structured fields: name, email, phone, work history (per-role), education, skills.

What parsers can handle in 2026 that they couldn't in 2018:

• Two-column layouts (the parser keys off semantic structure, not visual columns).
• Tables (most parsers either flatten them or extract rows correctly).
• Most fonts (custom fonts get rendered via the underlying font tables in the PDF).
• Modest graphics (logos, icons, headshots — parsed-around, not parsed-into).
• Em-dashes, en-dashes, smart quotes (no longer parse-killers).

What still trips parsers:

• Text rendered as images. A resume saved as a "PDF" where the entire content is one big image (some Canva exports, some Photoshop exports) has no text for the parser to extract. The system sees a candidate named "Untitled" with zero work history.
• PDF "form fields" or "annotations" instead of text. Rare but happens.
• Heavy use of text inside SVG / vector graphics. Some templates put your name in vector art "for design"; the parser sees nothing.
• Headers or footers with critical info. Most parsers ignore PDF headers/footers (because in real-world resumes they contain things like "Page 2 of 2", which is noise). Don't put your phone or email in a header.
• Non-standard section headings. "My Journey" instead of "Experience" / "Work History". The parser uses these headings to identify which section is which; weird headings cause weird parses.

Quick parseability test: Open your PDF in any PDF viewer, hit Ctrl-A (Cmd-A on Mac) to select all, copy, then paste into a plain text editor. If the result is clean readable text in roughly the right order, the parser will be fine. If the result is empty or scrambled, you have a problem the parser will also have.

Step 2: Indexing (the boring middle)

Once parsed, your resume gets stored in two places:

1. Structured fields (name, email, employer 1, title 1, dates 1, employer 2, etc.) for queries like "show me everyone who's worked at Google."
2. Full-text index for queries like "show me everyone whose resume mentions Kafka."

If the parser failed at step 1, your data is missing from these queries. This is the source of the "I never heard back" experience — not that you were rejected, but that you were invisible to the recruiter's query.

Step 3: Scoring (where the modern intelligence lives)

Most enterprise ATS systems now ship a scoring layer that produces a number (or 1-5 band) for each application against the JD. Three approaches, often layered together:

a) Keyword match. The classic. Take the JD, extract the keywords (skills, tools, titles), check which appear in the resume, score by overlap. This is what "ATS keywords" guides on the internet are still about, and it's still a real signal — but it's no longer the only one.

b) Semantic match. Use embeddings (vector representations) of the JD and the resume to score similarity. This catches "you used 'PostgreSQL' but the JD said 'Postgres'", which keyword-match misses. Most 2024+ ATS deployments have a semantic layer in addition to keyword match.

c) LLM judge. An LLM (often GPT-4-class or a fine-tuned model) reads the resume and the JD and produces a structured judgment ("Strong match on backend; weak match on team-leadership requirements; mid-match on industry"). This is the 2025-2026 frontier. Companies using it report higher recruiter trust because the LLM can explain its reasoning, which the keyword and embedding layers can't.

For your resume, the implication is:

• Keywords still matter. Don't write a resume that omits "Kubernetes" when the JD asks for "Kubernetes" — both keyword and semantic layers will down-rank you.
• But context matters more than count. Stuffing "Kubernetes" 15 times into a resume to game the keyword count doesn't help — the LLM judge sees keyword stuffing as a red flag, and the semantic layer doesn't increase the score for the 12th mention.
• Structure helps the LLM. Clear section headings, dated roles, quantified bullets — these all give the LLM judge cleaner anchors for its reasoning. A resume that reads well to a human reads well to the LLM.

How the major vendors actually behave (2026)

Treating "ATS" as a single thing is the source of most bad advice. The behavior differs meaningfully between vendors. Here's what we've observed across our analyzer's traffic + recruiter conversations + published vendor docs:

Workday

• Market share: the largest enterprise ATS by usage. Most Fortune 500 + most large healthcare, finance, and federal employers run Workday.
• Parser: handles single-column reliably; multi-column extraction is the weakest of the major vendors — text from sidebars sometimes gets concatenated incorrectly with main-content text.
• Scoring: weights job-title match heavily. If your previous title doesn't read as a clear seniority match for the target role, the score drops regardless of skills overlap. This is the single most consequential vendor-specific behavior — Workday users especially benefit from including the standardized title in their current-role line ("Senior Software Engineer" rather than "Code Warrior III").
• Application form: notoriously long, often 30+ fields including manually re-entering your resume contents. Workday-using companies see higher application abandonment rates from this UX alone, which means if you finish the form, you're already in a smaller candidate pool.
• Date format: prefers "MMM YYYY" or "YYYY"; struggles with "Spring 2022" or "Q1 '24".
• LLM layer: Workday has shipped Workday Recruiter Agent (their LLM-augmented screening tool) with rollout accelerating in 2025-2026.

Greenhouse

• Market share: dominant in tech/SaaS, especially Series B-D startups. If you're applying at a YC-backed company, it's probably Greenhouse.
• Parser: excellent. Handles two-column, modest graphics, embedded icons. PDF + DOCX have parity.
• Scoring: more permissive on title variance than Workday. Cares more about skill keyword overlap + dates of relevant experience than exact title match.
• Application form: typically shorter (5-15 fields) because Greenhouse customers are usually startups that prioritize candidate experience.
• LLM layer: Greenhouse integrates with multiple third-party screening AIs (Eightfold, Paradox, internal pilots) rather than shipping one as default.

Lever

• Market share: common in mid-market tech and growing startups.
• Parser: strong on PDF; some quirks with heavily-styled DOCX (custom fonts can occasionally render section headings as graphics, losing the section labels).
• Scoring: Lever's AI tier ships with built-in candidate ranking. The 2026 update is more aggressive than Greenhouse's — Lever will affirmatively rank candidates without recruiter prompting.
• Application form: consistently short and clean (often just resume + 2-3 questions).

Taleo (Oracle)

• Market share: large enterprise legacy installs — many Fortune 1000 companies still use it because the migration cost to Workday/Greenhouse is high.
• Parser: the weakest of the major vendors. Notoriously brittle on PDFs from non-standard tools; multi-column layouts fail more often than they succeed; some special characters break the parse entirely.
• Practical implication: if you suspect a target company is on Taleo (often visible in the URL of the application portal — taleo.net), prefer DOCX upload over PDF, and use the most-conservative single-column layout you have.
• Scoring: primarily keyword-match against the JD; semantic/LLM layers are minimal in Taleo's default configuration.

iCIMS

• Market share: large in industries with high-volume hiring (retail, healthcare, hospitality, manufacturing).
• Parser: middle of the pack. Better than Taleo, weaker than Greenhouse.
• Scoring: keyword-match with optional employer-configured filters. iCIMS-using companies are more likely to have automated rejection thresholds configured (because their hiring volume forces aggressive filtering).

SmartRecruiters, SuccessFactors (SAP), Ashby, Rippling Talent

• Smaller market share individually; mostly modern parsers with strong PDF handling.
• Ashby and Rippling especially are 2023+ designs and ship with semantic-match scoring as default. They behave most like Greenhouse.

The universal rules that survive every vendor

Single-column, reverse-chronological resume with standard section headings, "MMM YYYY" dates, and the target-role-standard job title in your current role line. This combination achieves ~95% parse fidelity across every vendor in the list above — based on parse-fidelity tests run by resumeoptimizerpro.com and our own analyzer's instrumentation in 2025-2026. Everything else is platform-specific optimization at the margins.

What "ATS-friendly" actually means now

Filter the advice you see online through this list. ATS-friendly in 2026 means:

• Text-based PDF, not an image. This one thing alone fixes 80% of "the ATS rejected me" cases.
• Standard section headings ("Experience" / "Work Experience" / "Professional Experience"; "Education"; "Skills"). Pick one, use it.
• Reverse-chronological work history with employer, title, dates, and bullets per role.
• Job titles that match (or are obvious translations of) industry-standard titles. "Code Warrior III" might be your internal title; "Senior Software Engineer" is what the parser will index. Use the standard title or include both.
• Dates as "MMM YYYY" or "YYYY", not "Spring 2022" or "Last summer". Parsers prefer numerals.
• A real Skills section. Not infographic skill bars (parsers don't read bar widths), not a tag cloud — a simple comma-separated or comma-spaced list. 8-15 skills is plenty.

That's it. Everything else you might read about ("avoid headers and footers", "no graphics", "no fancy fonts") either doesn't matter anymore or matters only at the margins.

What's no longer true in 2026

A few pieces of conventional wisdom that you can ignore:

• "Two-column layouts kill your ATS score." Not true since ~2021 for the major vendors. Parsers handle two-column layouts fine, as long as the column structure is semantically meaningful (left column = sidebar with skills + education; right column = main content). They don't handle two-column layouts where the visual columns chop a single block of prose in half — but that's a layout you wouldn't use anyway.
• "PDF is worse than DOCX for ATS." Was true around 2017. No longer true. Most enterprise ATS vendors have parity parsers, and PDF is more reliable because the formatting is locked.
• "You should use a separate plain-text version of your resume." Was a real workaround in 2016. Now unnecessary — but if a specific portal asks for plain text, paste plain text.
• "Add 'ATS optimized' to the bottom of your resume." This was a weird trend in 2022. Don't.

The single thing that has the most impact

If you can only do one thing to improve your "ATS performance", it's this: make sure the keywords in the JD appear naturally in your resume, in bullets that prove you actually did the work the keyword describes.

Not in a "Skills" wordcloud. In bullets. The keyword in a bullet that says "Reduced p99 latency from 1.4s to 280ms by migrating the checkout service to Go" is 4x more valuable than the same keyword in a Skills list, because both the LLM judge and the recruiter can see context of how you used it.

To find the exact keywords missing from your resume against the JD you're targeting, run both through our ATS Score tool — it surfaces the per-keyword gap and shows you where to add each missing keyword as a real bullet (not a stuffed list).

A realistic mental model

A useful way to picture it: the modern ATS is a librarian sorting submissions onto the recruiter's desk. It's not the gatekeeper deciding who gets hired. The gatekeeper is the recruiter. The librarian's job is to put the most-relevant resumes near the top of the pile, with a short label explaining why.

Your job, as the candidate, is to write a resume the librarian can read clearly and label confidently. The bulk of "ATS optimization" is just that — writing a resume that's clear, well-structured, and honest about what you did. The rest is at the margins.