Resume Parser: What It Pulled From One Resume in 37 Tests

TL;DR: A resume parser is the software that turns your file into database fields: name, phone, each job's title, employer and dates. We ran one resume through an open-source parser in 37 variants. It kept clean layouts intact but lost 8 of 14 job titles, filing them as the employer, and dropped one-line job entries, a dotted phone number and "Columbus, Ohio". Check how your own file parses before you apply.

What does a resume parser do?

Resume parser: software that extracts the text from a resume file and sorts it into structured fields (contact details, positions, education, skills) so an applicant tracking system (ATS) can store, search and pre-fill them.

Parsing is the first step after you upload. Ranking, searching and knockout questions come later and work on whatever the parser produced. If the parser files your job title as a company name, a recruiter's search for that title does not find you, even though the title is visible in the PDF. For the later ranking step, see how AI resume screening works.

The OpenResume parser, an open-source tool and the top result for "resume parser" in our search data, documents four steps: "Read the text items from a PDF file", "Group text items into lines", "Group lines into sections" and "Extract resume from sections". Here is what each step produced from the clean version of our test resume:

Step 1 is less neutral than it looks. We also exported the same file with poppler's pdftotext in its default mode, which reads by text flow. It printed the second job's dates, "Jun 2019 – Feb 2022", after that job's two bullets, and the graduation date "May 2019" after the skills line. The two extractors read the same file in two different orders, and whatever a parser does in steps 2 to 4, it can only work with the order step 1 hands it.

How we tested: one resume, 37 variants

On 13 October 2026 we built one fictional resume for Riley Morgan, a marketing coordinator: a name, one contact line, a summary, two jobs with two bullets each, one degree and a skills line. We rendered it as a US Letter PDF in Helvetica with @react-pdf/renderer 4.9.0 and changed one detail per file:

• Job title of the current role: 14 titles, from "Marketing Coordinator" to "Sous Chef".
• Date format of the current role: 10 formats, including "03/2022", "Spring 2022" and "’22 – ’24".
• Entry layout: 5 ways to arrange title, employer and dates.
• Phone format: 7 formats. Location: 5 formats.

That is 37 distinct files. We parsed each with the OpenResume parser at commit 4f8255a, run in Node with pdf.js 3.7.107. The only code changes were swapping the browser PDF loader for the Node one and stubbing one constant from the app's state store. The project page says the algorithm "is designed to parse single column resume in English language", so our resume is single-column English throughout.

Two limits matter. First, OpenResume is a rule-based parser written for a resume builder. We could not run Workday, Greenhouse or Textkernel, so we do not claim they make the same mistakes; the section on commercial parsers covers what their documentation says. Second, every result below comes from a generated PDF, so the text layer is clean. A scanned or design-tool export adds extraction problems on top of these. We kept the full output and both scripts, so every number below can be rerun.

Results: what the parser kept and what it lost

The clean file parsed perfectly: every contact field, both jobs, the degree and the skills line landed in the right place. The variants are where it went wrong.

The dates deserve a second look. Nine formats came back, but as typed strings: "Mar 2022 – Current", "Mar 2022 to Now" and "2022-03 – 2024-05" were stored character for character. This parser does not convert a date into a start month and an end month, so a system built on it cannot compute your years of experience. Textkernel's commercial parser does convert dates (see below), which makes a consistent, complete format matter more there.

The phone and location rules are short regular expressions in the source. The phone rule accepts three digits, an optional space or hyphen, three digits, an optional space or hyphen and four digits, with optional brackets; dots are not in it. The location rule expects a capitalised city, a comma and a two-letter state code. "Columbus, OH" was the one location format in our set that this parser accepted as written.

Why job titles and one-line entries broke

The job-title result is the one most likely to cost an interview, and the source code explains it. The parser holds a list of 69 job-title words (Analyst, Coordinator, Engineer, Manager, Nurse, Assistant and so on) and gives a line 4 points if one of its words is on that list. A line with a number loses 4 points, and a line over five words loses 2. The employer is the bold line left over once the title and date are taken.

"Account Executive", "Product Owner", "Paralegal", "Copywriter", "Pharmacist", "Sous Chef", "Social Media Strategist" and "Content Marketer" contain no word from the list. With no title found, the employer rule picked the bold title line instead, and the real employer was dropped from the record. "Executive Assistant" passed because of "Assistant", and "Software Engineer II" passed because of "Engineer".

Greenhouse, the ATS, points at the same weakness in its own parser. Its unsuccessful resume parse article lists "Resumes with incomplete job titles. For example, Sr. Account Exec instead of Senior Account Executive" and "Company names that don't include identifying words such as Inc., Co., LTD, or LLC." among its causes. When a parse fails there, the article says, "you'll need to manually input the candidate's details into the fields."

One-line entries failed for a different reason. "Marketing Coordinator | Harbor Health Partners | Mar 2022 – Present" is one text item, and the parser scores whole items. It cannot split one line into three fields. The line won the date score (it contains a year and "Present") and the employer score (it is bold). For the title, "Coordinator" earned 4 points, but the same item holds a number (minus 4) and more than five words (minus 2), so the score fell below zero and the title came back empty. The three layouts that kept every field put the title, the employer and the dates in separate text items: on separate lines, or with the dates aligned right on their own.

What to do with this:

1. Write the full, standard title. If your employer used an internal title such as "Growth Ninja", put the title a recruiter would search for next to it ("Growth Marketing Manager").
2. Give title and employer their own lines, with dates aligned right or on the employer line.
3. Use one date format throughout, with four-digit years: "Mar 2022 – Present" or "03/2022 – 05/2024".
4. Write your location as "City, ST" and your phone as "(555) 014-2290" or "555-014-2290".

Our ATS-friendly resume format guide covers the layout side: columns, tables, headers and letter spacing.

What commercial parsers do differently

Textkernel, a resume-parsing vendor that sells its parser to software makers as an API, publishes that API's documentation, and it shows how much more a commercial parser does in step 4.

Dates are converted. Each position's start and end date comes back as "The ISO 8601 (yyyy-MM-dd) date", with flags called FoundYear, FoundMonth and FoundDay that record which parts were in the text, and IsCurrentDate, "True if this date represents '- current' and not an actual date". When the month is missing, the API reference says a start date's day and month "will be 01" and an end date becomes "YYYY-12-31". So "2019 – 2022" is stored as 1 January 2019 to 31 December 2022, a longer tenure than you may have worked. Writing the month avoids that guess.

The parser needs the document date to read "Present". The same reference calls DocumentLastModified a "Mandatory date, in YYYY-MM-DD format, so that the Parser knows how to interpret dates in the document", and Textkernel's getting-started guide calls this setting "100x more important than any other setting when parsing resumes".

Titles and skills are normalised, as paid options. With profession normalisation switched on, "the most recent 3 job titles will be normalized", with a value from Textkernel's taxonomy plus O*NET and ISCO mappings. With skills normalisation on, "Raw skills will be normalized." The API also has a UseLLMParser option: "When true, the LLM parser will be used." A taxonomy is built to recognise titles that a 69-word list misses, such as "Paralegal", but the documentation limits it to your three most recent titles, and it only runs if the software maker pays for the option.

Textkernel's Resume Quality codes show what its parser still flags: code 221, "Indicates if any jobs were found without job titles", codes 224 and 225 for jobs without start or end dates, and code 418, "Dates ranges were found written vertically on multiple lines". Two of them, jobs without a title and jobs without dates, are failures our test produced, here flagged by a far larger parser.

How can you check how your resume parses?

Three checks, from fastest to most detailed:

1. Copy-paste test. Open your PDF, select all, paste into a plain text editor. Read top to bottom: each job's title, employer and dates should sit together and in order, and no line should be broken into stray letters. This shows step 1, the text layer.
2. Run a parser. The OpenResume playground runs in your browser ("File data is used locally and never leaves your browser") and shows the fields it extracted, the same parser we tested. If it misses your title or files it as the employer, treat that as a warning sign and rewrite the line.
3. Run an ATS check. Our free ATS checker extracts the text from your PDF or DOCX and flags a missing email or phone, missing Experience, Education or Skills headings, and mixed date formats.

None of these reproduces a specific employer's system, and no public tool can. Use them to remove the failures that a simple parser and the vendor documentation agree on. If your current title is unusual, check how it parses before you send the file.

What does a resume parser do?+

It extracts the text from your resume file, splits it into sections and fills structured fields such as name, phone, job title, employer, dates, degree and skills. The ATS stores those fields, and recruiters search and filter on them.

How can I check the parsing of my resume?+

Paste the PDF's text into a plain text editor to check the reading order, then run the file through a free parser such as the OpenResume playground to see the extracted fields. In our test, unusual job titles and one-line job entries were the details most often filed in the wrong field.

Is a resume parser the same as an ATS?+

No. The parser is one component of an ATS. The ATS adds search, ranking, knockout questions and the recruiter's workflow on top of the fields the parser fills. Parsing vendors such as Textkernel sell their parsers to software makers as an API.

Do parsers read 'Present' and 'Current' correctly?+

The open-source parser we tested stored both as typed text. Textkernel's documentation describes a flag for dates that mean '- current', and says the parser needs the document date to interpret them.

Key takeaways

• A parser decides what a recruiter can search for: a title filed as an employer is invisible to a title search, even though it is printed on the page.
• In our 37-variant test, the clean layout parsed perfectly; the losses came from job titles outside the parser's word list, one-line job entries, dotted phone numbers and spelled-out states.
• Greenhouse's own parse-failure list names incomplete job titles and company names without Inc. or LLC, so the title and employer lines carry real risk beyond our one parser.
• Textkernel's parser converts dates to ISO dates and fills a missing month with a fixed default, so "Mar 2022 – Present" is safer than a bare "2022".
• Test the exact file you send: copy-paste for the text layer, a parser playground for the fields.