How an ATS Reads a Resume: Parsing, Fields, and Search

After you upload a file, how an ATS reads a resume is a short path: extract text, map that text into fields, then let a recruiter search those fields. Some of the file never becomes searchable. The sections below stay on that path. They stop before any verdict.

How an ATS reads a resume: from upload to text

The first step is text, not a judgment. Workable’s parsing explainer defines parsing as extracting data from the resume’s text and ignoring the visual design. A name drawn inside an image does not survive that step, because there is no text to extract. Tables and columns can also put words on lines you did not intend.

A technical walkthrough from ATS CV Builder splits the start of the pipeline the same way: the system takes the file, identifies the type, and pulls text. A DOCX file is structured text. A PDF works when it still has a text layer. A scan is a picture. That walkthrough notes that some products try optical character recognition and many skip the picture entirely. Do not assume a success rate. None of these pages publishes one you should treat as universal.

A developer’s account on DEV Community describes the same opening move: convert the document to plain text. Scanned PDFs, text sitting inside images, and complex tables break there. Read that page as a developer’s view of the pipeline, not as a tutorial for building a parser, and not as a claim that every product fails in the same place.

Resume parsing: what the text step keeps

In this sequence, that step is the text extraction plus the decision about what to keep. Workable’s page says the parser looks for words and phrases it expects in a resume: names, job titles, companies, schools, and places. It also says the parser is weaker on novelty. A freshly invented job title is harder to recognize than a plain one.

ATS CV Builder describes the next cut inside the text: known section headers divide the document into zones, and inside each zone the parser looks for entities such as an email, a phone number, a title, dates, a degree, or a skill. Those entities are what later become fields. The DEV Community walkthrough says much of that detection is pattern matching against known headers and familiar shapes, not a human reading. Treat that as one developer’s description of common parsers, not as the source code of every product.

What the text step keeps is selectable words in an order the extractor can follow. What it drops is decoration: color, font flair, and anything that was never text.

Section labels become fields

After text exists, standard labels tell the parser where to put it. Workable recommends ordinary section titles such as “Education,” “Work Experience,” and “Personal Details.” ATS CV Builder lists a similar set that shows up across products: Experience, Education, Skills, Certifications, and Summary. The parser uses those labels as markers, then maps what sits under them into database fields a recruiter can open later: name, contact, titles, employers, dates, degrees, skills.

An opened comparison on Jobloo is enough to show that products do not share one identical field list. The same file can be stored differently from one product to the next. Do not memorize a vendor chart from that page, and do not treat one product’s miss as every product’s miss. There is no universal matrix in this draft.

Illustrative field map (not a dump from one vendor): contact details become contact fields, roles and dates become experience fields, schools and degrees become education fields, and a headed skills list becomes a skills field a recruiter could search. If the label is missing, that last step may never happen.

What never becomes searchable

Text never becomes a searchable field when extraction or mapping fails. These cases are illustrative, and they match limits the opened sources describe. They are not a promise about every vendor.

• Text in an image. Workable’s example is a banner drawn in an image editor. The name and contact details look visible to you and are absent after extraction. Greenhouse’s help page, cited below, lists graphics, photos, word art, and a resume uploaded as an image among parse problems.

• A heading the parser does not recognize. ATS CV Builder and the DEV Community walkthrough both use creative labels, in place of “Experience,” as a way the work history can land in the wrong place or stay unstructured. Call that a mapping limit, not a law.

• Unlabeled or scrambled text. A skills list with no heading, words inside a text box, or a two-column layout that the extractor reads across the page can stay unstructured. Workable notes that columns and tables reorder words, and that headers and footers are often mixed into the body or lost. The DEV Community page describes the same column problem: lines from the left and right can interleave.

If it never becomes a field, a later search cannot find it. That is a storage gap, not a verdict.

How an applicant tracking system reads a resume once fields exist

Once fields exist, a recruiter searches those fields. Workable’s explainer says the stored data is what someone can search. ATS CV Builder calls the last structural step indexing, so a recruiter can search and filter the structured record rather than the original decoration. The opened ATS Grader guide supports that search half: recruiters look through the fields parsing stored. Do not follow that guide past search. Any verdict question belongs in the handoff section, and this page does not explain it.

Jobloo’s comparison is relevant only as a warning that “the fields” are product-specific. Search can only return what that product managed to store. It cannot return a name that never left an image, or a skill block that never received a heading.

Illustrative search, not a case study: a recruiter types a skill and a city that were mapped into fields. Your resume is findable for that query only if those words survived extraction and landed in a field. The original layout is not what gets searched.

How ATS resume parsers actually work when a heading is missing

On this one point, the behavior is a field-mapping failure. ATS CV Builder says a creative heading such as a slogan in place of “Experience” can push work history into the wrong zone. The DEV Community walkthrough describes section classification as a check against known headers. An unknown header can leave the block unclassified, so the jobs under it never become experience fields.

That is still mapping, not a verdict. The text may even sit somewhere in the extracted blob. It is not in the field a recruiter filters when they ask for experience. Standard labels the opened sources name — Experience or Work Experience, Education, Skills, Summary — are the ones these parsers are described as expecting. A missing label is a reason to rename the heading on your file, not a reason to invent new jobs under it.

When the parse fails

Greenhouse’s help page describes an unsuccessful resume parse in operational terms. When a parse works, Greenhouse fills candidate fields from the file. When it does not, the resume is only attached and a person has to type the details into the fields. A parse can also be partial: some fields fill, others stay blank.

Greenhouse names causes on that page, for that product only. The file can be too large to parse (larger than 2.5MB). Placeholder-looking data, such as an obvious stand-in name or title, can be skipped. Formatting can block the fill: graphics, photos, or word art; a file that is an image rather than a document; tables; content in a header, footer, or text box; a columned layout; unclear sections. Those are reasons the fields stay empty or incomplete. They are not a grade of the candidate.

One vendor help article on parsing, from Lever, was not readable for this draft. This section does not describe that product’s fields and does not quote the page.

Questions this page hands off

A verdict on a resume is a different question. This page does not answer it. Use Alignlie’s separate post for that question.

FAQ

Does the file type matter to parsing?

Only insofar as the system needs text it can read. Workable and the DEV Community walkthrough both treat a word-processor document, or a PDF exported with a real text layer, as text that can be extracted. A scan is a picture. ATS CV Builder notes that some systems try to read pictures and many do not. There is no file-type success rate in this draft.

If a heading is creative, does that text still become a field?

Often it stays unstructured. That is a mapping limit described by ATS CV Builder and the DEV Community walkthrough, not a rule for every vendor. If you need the block to be findable as experience, education, or skills, use a plain label those parsers expect.

Where should verdict questions about a resume go?

Not in this article. Use the handoff section above and stop. This page does not explain them.

Conclusion: Searchable fields, not a verdict

How an ATS reads a resume is the path from file to text, from text to fields, and from fields to a recruiter’s search. Images, unrecognized headings, and unlabeled blocks can remain unsearchable. A failed parse, in Greenhouse’s own help, means the fields were not filled and someone has to enter them. That is as far as this page goes. It does not hand down a verdict.