1. 1ATS Parser
2. 2ATS Job Ranking
3. 3Recruiter Screen
4. 4Hiring Manager Review

How an ATS parser reads your resume

Step 1 of 4 · 6 min read

The first reader of your resume never sleeps and never skims. Seconds after you click Apply, a parser inside the company's applicant tracking system takes your PDF apart and files the pieces into a database. It has no opinion about your work. But everything that happens next, from the ranking to the recruiter's search, runs on what it wrote down.

What is an ATS parser?

An ATS parser is software that converts your unstructured resume into a structured record. It reads the text, finds your contact details, works out where each section starts, and splits your experience into entries, each with a title, an employer and a pair of dates. Then it builds a list of your skills and, for each one, works out how many months of experience your resume backs it with.

That record is what the rest of the hiring process sees. When a recruiter searches for "Kubernetes, three years or more, senior", they aren't searching PDFs. They're searching the fields the parser filled in. A resume that reads beautifully to a person can come back from the parser with two jobs merged into one, the skills section glued onto the last job, or Python credited with zero years.

Where do your years of experience come from?

This is the part almost nobody is told, and it matters more than anything else on this page: the years an ATS credits to each skill are no accident. They come from your format.

Textkernel, one of the most widely used parsing engines, reports two things for every skill it finds: MonthsExperience, and FoundIn, the places in your resume where it found the skill. The months come only from jobs. If "Go" appears in the bullets or tech stack of a job you held for 38 months, Go gets 38 months. If it appears in two jobs, their months add up.

A skill that lives only in your Skills section or your summary is found, but it earns nothing. On one engineer's resume in our tests, 49 of the 105 skills the parser found had zero months for exactly that reason. To a search for "three years of Kubernetes", those skills might as well not be there.

What did we learn testing real parsers?

We didn't want to repeat folklore, so we tested. We printed resumes from ResumeBuilder and ran them through Textkernel Tx (formerly Sovren) and Affinda, two of the parsing engines behind many applicant tracking systems, and through Klippa. Then we compared every field that came back with what the resume actually said.

Section headings: boring wins

A parser finds a section by its heading. We changed every heading on each test resume to see which ones survived. The standard ones did:

The creative ones didn't. "About Me" was read as work history. "Where I've Worked" and "What I Bring" were missed. And the one that surprised us: "Skills & Tools" worked, but "Skills and Tools" didn't, and the whole skills block ended up inside the candidate's last job. One word was the difference.

Several titles at one company: the layout every parser broke

Many engineers list one company and stack their titles under it, to show a promotion. It looks tidy. No parser we tested handled it. Textkernel merged two roles into one position covering the whole span, so a skill used only in one of the roles was credited with 54 months instead of 16. Affinda read the team name as the employer. Klippa lost the second role's dates.

With one entry per title, each with its own dates, Textkernel read both positions correctly and that skill got its 16 months. Repeating the company name didn't make the parser count an extra employer, so it doesn't read as job hopping. That's why ResumeBuilder gives every title its own entry.

Titles carry your seniority, and page breaks can cost you

Parsers read your level from your job titles, not from what your bullets describe. "Senior", "Staff", "Lead" or "Principal" in a title is what moves you up a search filter. And at a page break, some parsers lose their place: lines at the top of page 2 can come loose from the job they belong to.

How does ResumeBuilder optimize for the parser?

The format does most of the work before you type a word. The PDF is printed from the same page you see in the editor, in one column, so every word is real text in reading order. Every job is one title, one employer and one date range, with its own tech stack line, so your skills earn their months.

The ATS Parser step then checks what the format can't. It flags a section heading that isn't on the list above and offers the standard ones. It asks for city and state instead of a street address, which adds nothing and can trip location filters. It turns link labels like "GitHub" into addresses a parser, or a printed page, can keep. It gives you a heads-up when your resume is exactly two pages, so you can check what sits at the break.

Most importantly, it looks at the skills that set candidates apart most: your domains, your core expertise, and your leadership. If your strongest skills in one of those earn too few years, usually because your bullets show the work without naming it, the check points at those bullets and suggests wording that names the skill. Same work, same honesty, more years credited.

Frequently asked questions