What Recruiters See When an ATS Parses Your Resume

Here is the short answer. When you apply through an applicant tracking system, the recruiter does not open your resume file first. They see a candidate record the system built from it: your name, contact details, job titles, employers, dates, skills, and education, extracted into separate database fields. If the parser failed to read a section, that field is simply blank. And because recruiters search and filter on those fields, a blank field does not look like a formatting problem on their side. It looks like you never had the experience at all.

So the question that actually matters is not "will the ATS reject me?" It is "what does my record look like after parsing, and can a recruiter find it?" This guide walks through what that record contains, how it gets built, and where the data falls out.

The parse happens before any human looks

Resume parsing runs as a staged pipeline. First the parser segments your document into standard sections: work experience, education, skills. Then it categorizes what it finds into typed fields, recognizing "January 2018 to April 2022" as a date range and "Software Engineer" as a job title. Finally it indexes that structured data so recruiters can query it. This pipeline shape is consistent across the industry; commercial parser vendors like Affinda document it directly, and resume-tooling guides describe the same three stages.

The implication is easy to miss. Your resume is not evaluated as a document. It is converted into data, and everything downstream, every search, every filter, every shortlist, runs on the data, not the page you designed.

The fields your record contains

Parser documentation gives a concrete picture of what gets extracted. Affinda's resume parser, one of the commercial engines that power these systems, enumerates over a hundred fields. The core set looks like this:

• Personal details: your name, split into first, middle, and last.
• Contact: phone, email, websites, and location.
• Work experience: for each role, the job title, organization, industry, location, start and end dates, whether it is current, and the description.
• Skills, often mapped to a taxonomy with an estimate of months of use.
• Education: institution, degree, GPA, and dates.
• Languages, certifications, and publications.

That is the record. When a recruiter pulls up your application, this is the spine of what they see: a profile assembled from those fields, usually with the original file attached as a secondary artifact. The file is the source. The record is the product.

How parse failures surface: as blank fields

Parsing does not fail loudly. There is no error message on the recruiter's screen saying "this resume used a two-column layout." The data is just missing, or scrambled into the wrong field.

The most damaging single failure is contact information placed in the document's header or footer region. Some enterprise parsers treat that part of a Word file as a separate layer and skip it entirely. In one small empirical test of eight ATS platforms, six missed contact details placed in a Word header, producing candidate profiles with no name or contact information. Eight systems is not the whole market, but the mechanism is real and the fix is trivial: put your name, email, and phone in the body of the document, at the top.

Layout is the other major source of loss. Naive parsers read a page top to bottom and left to right, which interleaves columns and slices tables apart. In that same eight-system test, a two-column resume parsed incorrectly in seven of eight platforms, tables were skipped in five, and sidebar text boxes were dropped outright in four. A 2025 research paper found parsing accuracy dropped measurably on multi-column resumes when the text was not reordered first. Two honest caveats: modern layout-aware parsers handle columns better every year, and none of this is a universal hard failure. Treat it as graduated risk, with text boxes and sidebars riskiest, then tables, then columns.

Smaller details leak data too. Text inside graphics and images is generally not read at all, and decorative bullet glyphs can be replaced with junk characters or cause bullets to merge into one paragraph. A skills chart rendered as an infographic is, to the parser, an empty region.

What recruiters do with the record

Once your data is indexed, recruiters work the way anyone works a database: they search and filter. Title searches, skill searches, location filters, date ranges. This is where the "blank field" problem compounds. If your last three job titles never made it into the title field, you do not appear in a title search. You were not rejected. You were never in the result set.

Some systems also compute a match score against the job description. Workday, for example, can rank candidates by a descending match percentage. But scoring is not universal: Greenhouse uses human-graded scorecards rather than an algorithmic rank, and Lever surfaces semantic relevance without a candidate-facing score. And in interviews with 25 US recruiters conducted in late 2025, most treated such scores as rough sorting aids rather than decisions; only two ran systems configured to auto-reject on a low match. The same small survey found 23 of the 25 saying their systems never auto-reject on formatting, content, or missing keywords. Twenty-five recruiters is a small, self-reported sample, so hold the exact percentages loosely. The direction, though, is consistent across sources: humans do the rejecting, and the automated gates that do exist are mostly eligibility questions like work authorization, not resume content.

Recruiter review time is short. A recruiter triaging a high-volume role is scanning the parsed profile, not studying your document, and a profile with clean titles, complete dates, and a populated skills field gives them something to act on in that window. A profile with gaps gives them a reason to move to the next one.

The takeaway: completeness and clean extraction

The ATS is not a judge. It is a transcriptionist with strong opinions about formatting. What decides whether you surface is whether your record comes through complete: every role with a title, an organization, and a real date range; contact details in the document body; skills stated as text, not pictures; a single-column layout that parses in order.

Before you send a resume anywhere, look at it the way the machine will. Could every field in the record above be filled from what is on the page, by a literal-minded reader going top to bottom? If yes, the recruiter sees you. If not, fix the source, because the parsed record, not the PDF you polished, is what they are actually reading.

Sources

• Affinda resume parser API documentation (extracted fields and accepted formats) ↗
• QuickCV: an empirical parse test across 8 ATS platforms ↗
• Jobscan on ATS-friendly templates and the parsing pipeline ↗
• Enhancv recruiter interviews on what ATS actually reject (n=25) ↗