An ATS resume parser is the piece of software that opens your resume file and converts it into a database record. It pulls out the raw text, decides which chunk is your name, which is a job title, which is a date, and files each piece into a structured field a recruiter can search. Nobody reads your beautiful layout. They read the record the parser produced from it. That gap is where good candidates disappear: if the parser reads your two column resume in the wrong order or drops the email in your header, you become a broken record in a database nobody queries.
This guide covers what the parser extracts, what scrambles it, and how to see your own parse before you apply.
What an ATS resume parser actually does
Parsing runs before any human sees you, in roughly five stages:
Text extraction. Your PDF or DOCX is stripped down to a plain stream of characters. Anything that is not real text, like an icon, a skill bar graphic, or a screenshot of text, contributes nothing at this stage.
Sectioning. The parser looks for recognizable headings (Experience, Education, Skills) to split that stream into blocks.
Field recognition. Inside each block it hunts for known patterns and entities: things shaped like an email, a phone number, a date range, a company, a degree, a job title. Workable, an ATS vendor, describes matching resume text against known databases of names, job titles, companies, countries and cities to do this.
Record building. The extracted fields populate your candidate profile: current title, current employer, work history with dates, schools, skills.
Indexing. The full text plus those fields get indexed so recruiters can filter and search, usually against a specific job's requirements.
Stage 5 is the part job seekers care about, but stages 1 and 2 are where the damage happens. A keyword the parser never extracted cannot rank you for anything.
What an ATS resume parser extracts from your resume
Field
Where the parser looks
What breaks it
Name and contact
The top block of the document
Contact details in the header or footer, which many parsers skip entirely
Current title and employer
Your most recent Experience entry
A "Projects" or "About" block placed above Experience, which can be misread as your latest role
Work history and dates
Each Experience entry
Year only ranges, "Present" written creatively, dates parked in a separate column
Education
The Education block
Nonstandard headings such as "Where I Studied"
Skills
A Skills block plus anywhere in the text
Skills laid out in a table or a graphic rating bar
Full text index
The whole document
Text embedded in images, which never enters the index at all
What the parser sees is not what you see
Most parsers read a document as one linear stream, left to right and top to bottom, the same way you would read a page if you ignored the visual columns entirely. On a single column resume that matches what your eye does. On a two column resume it does not.
Take a common layout with skills in a narrow left column and experience on the right. You see two tidy columns. The parser can see this:
Plain text
Python Senior Data Analyst
SQL Acme Corp
Looker Jan 2023 - Present
Tableau Rebuilt the weekly reporting pipeline
Your job title is now glued to a skill, your employer to another, and no field is clean. Jobscan documented the same failure running a design heavy resume through Lever, where the parser picked up the work experience section and ignored everything else: no skills, no contact info, no links.
This is also why "the ATS rejected me" is usually the wrong mental model. Most systems do not delete anything. They store a record and let recruiters search it, so a badly parsed resume is not rejected, it just never comes back in the results.
How to see what the ATS parser sees
You do not have to guess. Three checks, cheapest first:
The copy and paste test. Open your resume PDF, select all, copy, and paste into a plain text editor (Notepad, TextEdit in plain text mode, or any code editor). What you get is close to what the parser extracts. Read it top to bottom: if your job title collides with a skill, if dates land in odd places, or if your email is missing, you have found your problem.
The save as text test. In Word, use Save As and pick Plain Text (.txt). Same idea, and it exposes tables particularly well.
Run a real scan. The tests above show the extraction, not whether you match the job. A scanner compares the parsed text against a specific posting and tells you which required keywords are missing.
If your pasted text reads cleanly in order, the parser will handle it. If it reads like word salad, no keyword tuning will save it, so fix the layout first.
Worked example: a bullet the parser can use
Parsing correctly is the floor, not the goal. Once the text extracts cleanly, it still has to say something a recruiter will rank. Here is a bullet that parses fine and does nothing for you:
Responsible for reporting and analysis for the marketing team.
It contains no tools, no scope, no result. A search for "SQL" or "dashboard" will not surface it. Rewritten:
Rebuilt the marketing team's weekly reporting in SQL and Looker, cutting manual prep from roughly 6 hours to under 1 and giving 12 stakeholders a self serve dashboard.
Same job, same truth, but now the record carries the tools (SQL, Looker), the scope (12 stakeholders), and an outcome. That is what a recruiter's search matches on, and what a human actually wants to read.
The honest answer is that the advice online genuinely conflicts. Jobscan recommends PDF unless the posting asks for .docx. Plenty of other tools argue DOCX parses more reliably because the file already carries heading structure, while a PDF stores text by position and the parser has to infer the structure back.
Both are defensible, and the argument matters far less than people think, because the file type is rarely what breaks a parse. How the file was built is:
A text based PDF exported from Word or a resume builder, single column, standard headings: parses fine.
A PDF exported from a design tool with columns, icons, and text boxes: parses badly regardless of extension.
A scanned or image based PDF: contributes almost nothing, since there is no text layer to extract.
So pick either format, make sure it is text based (run the copy and paste test above), keep it to one column, and follow the posting's instructions if it names a format. If you are starting from scratch, our free resume builder exports a single column, text based PDF by default.
Common parsing mistakes
Contact details in the header or footer. The area many parsers ignore is the worst possible place for your email.
Two column layouts. They look sharp to a person and scramble in a linear read.
Tables for skills or dates. Table cells frequently extract out of order, or not at all.
Creative section headings. "Where I've Made an Impact" is not a heading the parser can map to Experience.
Icons and rating bars instead of words. A picture of a skill is invisible in the text index.
Incomplete dates. "2023 to present" is weaker than "Jan 2023 to Present" for building a clean work history.
Fixing keywords before fixing extraction. If the text does not come out in order, keywords are irrelevant.
Where Dopplio fits
The self tests show you the extracted text. They do not tell you whether that text wins the role. Dopplio reads your resume the way a recruiter and an ATS both would, in one pass: paste the job description and you get your match score, the required keywords your resume never mentions, the bullets too vague to rank, and the formatting traps hurting the parse. Then it rewrites the weak bullets using only what is already true in your resume, with every change yours to approve.
It takes about 30 seconds, no credit card. For the scoring side in more depth, our guide to the ATS resume checker covers what gets scored and how to fix it.