What an ATS actually sees when it reads your resume

Ask anyone who has applied for sixty jobs and heard nothing back what went wrong, and they will usually blame the resume's content. Sometimes that is right. But a substantial share of silent rejections happen earlier than that — before a human, and often before any scoring at all — when the file is converted into text and the conversion goes badly.

We build a resume parser, so we spend our days looking at the output of that conversion across thousands of real documents. What follows is a walk through the actual stages, in order, with the specific failure modes each one produces. The useful mental shift is this: an applicant tracking system does not read your resume. It reads a flattened string of characters that used to be your resume.

1. It reads characters, not pixels

The first stage opens the file and pulls out its embedded text layer. A PDF is not an image of a page — it is a set of drawing instructions, and most of those instructions say "place this character at this coordinate in this font." The parser reads those instructions.

Which means: if there is no text layer, there is nothing to read. A resume exported as a scan, a photograph, or a design file flattened to an image parses as effectively empty. Most systems do not run OCR as a fallback, because OCR is slow, expensive and error-prone at scale.

This stage also filters. Our extractor drops any character whose font size is below about 1.5 points, and any character whose fill colour is near-white — every RGB channel at 0.95 or above, or near-zero ink on all four CMYK channels. That is not an accident of implementation. It is a deliberate defence against the oldest trick in the book: pasting a block of job-description keywords into the document in white-on-white, size-1 text, so a human sees nothing and a machine sees a perfect match.

It does not work. It has not worked for years. The hidden text is discarded before anything analyses it, and a growing number of pipelines log the attempt as a signal in its own right. If you have been advised to do this, you have been advised badly.

2. Reading order is guesswork — and columns break it

This is the big one, and the one almost nobody warns you about.

A PDF stores each word with its position on the page. It does not store the order you intend those words to be read in. Reading order has to be reconstructed, and the naive reconstruction — sort everything top to bottom, then left to right — is exactly what destroys a two-column layout. Every line of your left column gets glued to whatever happens to sit beside it in the right column.

A parser that handles this properly has to detect the column gutter first. The way ours does it is worth describing, because it tells you exactly what makes a layout safe or unsafe:

• Collect every word's left edge, and look for horizontal gaps wider than about 4% of the page width. On A4, that is roughly 24 points — a real gutter, not an indent.
• Ignore anything in the top and bottom 8% of the page, because a full-width header or footer spans both columns and masks the boundary underneath it.
• Ignore candidate gaps in the outer 5% margins, which are indentation noise rather than column boundaries.
• Keep only gaps at least 70% as wide as the widest one found. Real gutters are consistent down the page; a gap created by one unusually short line is not.
• Split into bands on what survives, read each band top to bottom independently, then concatenate.

Read that list as a specification for your own document. A two-column resume is not inherently doomed — ours handles them, and we test hardest on exactly this case. What kills it is an inconsistent or narrow gutter: a sidebar that is 15 points from the main column in some places and 40 in others gives the detector nothing stable to lock onto.

3. Your running header is deleted on purpose

Multi-page resumes often repeat a banner — Priya Raghavan · page 2 of 3 — at the top or bottom of every page. That is noise, and parsers remove it: if the first (or last) line of a page repeats verbatim on at least half the pages, it gets dropped before analysis.

Now consider what happens if you put your name, email and phone number in the actual PDF header region, as many templates do. On a two-page CV, that block repeats on both pages. It matches the running-header pattern perfectly. It is removed. The parser then reports a candidate with no name and no contact details — and a record with no email address is, from a recruiter's tooling perspective, unusable.

This is one of the most common and most invisible ways a good candidate disappears. Contact details belong in the body of the first page, as ordinary text.

4. Tables get flattened

In a DOCX file, table cells are not laid out in a grid when extracted — they are walked row by row and joined. Our extractor emits each row as its cells separated by a pipe:

Mar 2021 - Present | Senior Backend Engineer | Northwind Labs
Jul 2018 - Feb 2021 | Backend Engineer          | Cobalt Systems

That is recoverable — the date, title and company are at least on the same line, in order. But if you have used a table for layout rather than data, with your entire skills sidebar in one cell and your entire work history in the cell beside it, you get the same interleaving problem as columns, and the pipes make it worse.

Tables for tabular data: fine. Tables as an invisible layout grid: this is where they bite.

5. Sections are found by their headings

Once there is clean text, the parser has to work out which part is experience, which is education, which is skills. It does this by matching headings against a vocabulary of known synonyms — experience, work experience, employment history, career history, and so on.

A heading outside that vocabulary is not recognised as a heading, so the content underneath it does not get filed under the right section. It is not lost, exactly, but it stops being structured, and structured is the whole point.

This is where creative section names cost you. Where I've Made An Impact is a nice line. It is not an experience heading to a machine. The same goes for My Toolkit instead of Skills, or Chapters instead of Experience.

Worth noting: in our pipeline this particular failure is self-correcting over time. When local confidence is low, the document escalates to a language model, and whatever heading the model identifies is written back into the local vocabulary — so the next resume using that heading is handled without an AI call at all. But you cannot rely on the specific system reading your CV having learned your heading yet. Use a conventional one.

6. Job titles get normalised — so stop keyword-matching them

A common piece of bad advice is to rewrite your job title to mirror the advert exactly. Any competent matcher makes this unnecessary.

Before comparing titles, ours strips qualifier words — Sr., Jr., Senior, Junior, Staff, Lead, Principal, Associate, and roman numerals — then fuzzy-matches what remains against the O*NET occupation taxonomy. Sr. SDE II and Backend Engineer land in the same occupational family. Seniority is then derived separately from those same qualifier words, so it is scored as its own dimension rather than smuggled into the title match.

The practical consequence: use your real title. Inflating or contorting it to match a posting gains you nothing against a decent parser and costs you credibility with the human who reads it afterwards.

What this means for your resume

None of this is about making your CV ugly. It is about a handful of structural choices that are invisible to a reader and decisive to a parser.

• Ship a real text layer. Export to PDF from a word processor, never as an image or a flattened design file.
• Contact details in the body, on page one, never in the PDF header or footer region.
• If you use columns, make the gutter wide and perfectly consistent down the whole page.
• Use tables for data, not for layout.
• Use conventional section headings. Save the personality for the bullets underneath them.
• Use your real job title. Normalisation handles the rest.
• Spell out skills in the experience bullets, not only in a skills list — that is where the evidence lives.
• Never hide keywords. It is filtered, and increasingly it is flagged.

Frequently asked questions

Do two-column resumes get rejected by an ATS?

Not rejected — misread, which is worse because it is silent. A parser infers column boundaries from the horizontal gaps between words; when the gutter is narrow or inconsistent, the columns interleave line by line. A generous, consistent gutter is usually enough to make the layout safe.

Should I put my contact details in the header of the document?

No. Parsers strip first and last lines that repeat across most pages, because that pattern almost always indicates a running header. If your email lives there, it can be removed before analysis and the record comes out with no way to contact you.

Can an ATS read a resume saved as an image or a scan?

Generally no. Most parsers read the embedded text layer rather than running OCR. If you cannot select the text with your cursor, the parser cannot read it either.

Does hiding keywords in white text help get past an ATS?

No, and it is actively risky. Characters with a near-white fill colour or a font size below roughly 1.5 points are filtered out before analysis, and the attempt itself is increasingly logged as a signal.

Does my job title need to match the posting exactly?

No. Titles are normalised against an occupation taxonomy with seniority qualifiers stripped first, so Sr. SDE II and Backend Engineer resolve to the same family. Use your real title.