How ATS actually works

How to Test Your Own Resume Against a Parser

A tool-agnostic method you can run in ten minutes, including the free parser test hiding in every application portal you have ever used.

You cannot see the employer's parser. That is the whole frustration of this subject: the one reader whose opinion decides the outcome is the one reader who never reports back.

You can get closer than most people realise, though, and none of it requires buying anything. Here is a method that takes about ten minutes, uses tools you already have, and finishes with a specific list of things to change.

Step 1: the text layer test, ninety seconds

1. Open the file you are about to send.
2. Select all, copy.
3. Paste into a plain text editor. Not Word, not Google Docs, not an email. A text editor, so no formatting can rescue the result.
4. Read it.

What you are looking for is whether the words survived at all. Boxes, missing letters, mangled ligatures, or no text pasting at all means the document has no usable text layer. That happens with scanned files and with PDFs exported by some design tools, where text is stored as outlines rather than characters. A file in that state is invisible to every system in this cluster, and no amount of keyword work reaches it.

Step 2: the reading-order test, two minutes

Look at the same paste, but now at the sequence.

Does your skills sidebar appear in the middle of a job description? Do two columns interleave line by line? Is the header content missing entirely? These are the classic layout failures, and they have a specific cause: in a Word document a sidebar is usually a table cell, and cells are extracted one after another rather than side by side.

If the order in the text editor would confuse you, it will confuse a parser, because that sequence is all the parser gets.

Step 3: the role-count test, three minutes

This is the one almost nobody runs, and it catches the failure that matters most.

In your pasted plain text, count the job headers. Not the jobs you know you have. The lines that look like the start of a job: a line with a title-ish shape, followed by something date-shaped.

If you count more headers than you have jobs, you have found a real defect. Every PDF hard-wraps, the bullet glyph is drawn once, and continuation lines arrive with no marker. The last line of a wrapped bullet is short by definition, and a short line with no bullet and no dates looks exactly like the start of a new role.

We found this in our own reader: a four-role resume came back as six, with two invented jobs whose titles were fragments of sentences and which had no employer and no dates. In an employer's system those are two roles you cannot explain, and they pull your average tenure down.

If you find phantom headers, the fixes are mechanical. Shorten or lengthen the offending bullet so it does not end on a two-word stub. Make sure every real role has a date range in a consistent format, since dates are the strongest signal that a line is a header.

Step 4: the field test, two minutes

Write down, from your plain text alone, what a parser would store. Vendors publish these lists, so use theirs. Oracle documents Taleo storing name, address, city, postcode, phone, email, place of residence, education level, institution, programme, graduation and start dates, and for each job the start date, end date, employer, job function and responsibility.

Now check each one against your paste:

An empty box in that table is not a style note. Workable documents that when a name cannot be parsed from a resume, the candidate is recorded as "Uploaded Candidate". That is what a missing field looks like from the other side.

Step 5: the free test hiding in every portal

Here is the part most people miss. You have already been shown the employer's parser output, many times, and clicked past it.

Any application portal that offers to fill the form from your uploaded file is running its own parser and then showing you the result for correction. Workday's Autofill with Resume step does this. Oracle documents the same behaviour for Taleo, where you choose whether to use the resume parsing feature and the extracted values populate the candidate record.

Next time you meet one, stop and read it before you touch it:

1. Did every job come across, with the right employer against the right title?
2. Are the dates right, and are any roles undated?
3. Did the education level arrive, or only the abbreviation?
4. Are there roles in the list you do not recognise?
5. Is anything in the wrong field, like a title carrying "(promoted 4 times)"?

Then fix the form, and separately fix the document, because the next portal will parse it again from scratch. That screen is the closest thing to ground truth any candidate gets, and it is free.

Step 6: the search test, one minute

Pick the two or three terms a recruiter would actually type for this role. Search your document for each one as a word.

Present means present. Absent means you are not in that result set, and the fix is a rewritten bullet rather than an addition to a skills list. Which terms count as present, and what a parser will never work out for itself, is its own subject.

Step 7: the size check, fifteen seconds

Look at the file size. Oracle documents that a resume submitted to Taleo for parsing "cannot exceed 100 kilobytes or the size defined by the system administrator". A plain single-column DOCX is well inside that. A design-tool PDF with a photograph and embedded fonts is often not.

Step 8: the heading test, one minute

A parser matches your section headings against a vocabulary it holds. A heading it does not recognise loses everything underneath it, which is how a whole certifications block disappears from a record while sitting in plain sight on the page.

The safe set is boring on purpose: Experience or Work Experience, Education, Skills, Certifications, Languages, Publications. "Career Highlights", "What I Bring" and "My Journey" are headings for a human reader and a coin toss for a machine. If you want a distinctive line, put it in the summary rather than in a heading.

While you are there, check that no important detail lives only in a page header or footer. Those are frequently skipped, and a phone number is a common casualty.

What to do with what you find

Sort the results into two piles, because they have different owners.

Document faults are things the file did wrong: no text layer, scrambled order, phantom roles, missing dates, unrecognised headings, oversize file. You fix these by changing the document, and they stay fixed for every future application.

Content gaps are things the file said accurately and a search will still miss: an acronym in one form, a degree with no level word, a skill your bullets show and your page never names. Those need writing rather than reformatting, and only you can supply the facts behind them.

Keeping the two piles apart is worth the extra minute. Reformatting will never fix a missing word, and rewriting will never fix a missing text layer.

What our own check adds, and what it does not claim

Involve Resume runs a check called parse-back. It builds the real DOCX and the real PDF bytes of the document you are about to send, parses each one back with our own reader, and compares the recovered record against what went in, field by field: name, email, phone, location, how many roles came back, how many had dates, how many had employers, how many skills and qualifications survived. Then it names the format to send, with DOCX breaking a tie for the reasons in the format post.

The limitation is printed on the screen, and we would rather you read it here first. This is our reader, not the employer's. A different applicant tracking system will differ in detail, and no check on this side of the wall can tell you what theirs will do. What it proves is narrower than "this parses everywhere". A document our own reader cannot recover is a document no reader will recover, and every fault it has found so far has been a fault in what we wrote rather than in how we read it. That is a useful thing to know before you send a file, and it is not the same as a promise.

The ten-minute checklist

1. Copy to plain text. Is the text there?
2. Is the reading order sane?
3. Count job headers. Does the count match reality?
4. Check the eight fields above.
5. Read the next portal's parsed form before correcting it.
6. Search for the two or three terms that define the role.
7. Check the file size.
8. Re-run all of it after any template or length change.

Run it against a real posting when you are done, and start with the fields that did not survive.

Sources: Oracle Taleo, Candidate Management, Workable, Importing candidate data, SmartRecruiters, What is resume parsing, Greenhouse, Operational readiness guide: Talent Matching policy