How ATS systems actually read your resume

Most advice about applicant tracking systems is written by people who have never watched one fail. It tends to arrive as a list of commandments — no columns, no tables, use standard headings — with no explanation of what actually goes wrong. That makes the rules hard to apply, because you can't tell which ones matter for your particular resume.

So here is what is really happening to your file.

An ATS is three separate things

When people say "the ATS rejected me", they usually mean one of three different systems, and it matters which.

The parser turns your PDF or DOCX into structured data: name, email, phone, a list of jobs with dates, education, skills. This is the part that breaks most often, and the part you have the most control over.

The search and ranking layer is what a recruiter uses. They search for candidates who have "Python" and "5+ years", and the system returns everyone whose parsed record matches. If the parser missed something, it does not exist here.

The knockout questions are the form fields you fill in on the application — work authorisation, notice period, expected CTC. These are answered by you directly and do not involve your resume at all.

Almost nothing gets automatically rejected by the resume itself. What happens instead is quieter and worse: your record is created badly, so you never appear in the searches a recruiter actually runs.

What the parser is doing

A PDF does not contain paragraphs, headings, or sections. It contains text fragments with coordinates on a page. "Senior Product Manager" might be stored as three separate runs at three x-positions that happen to sit next to each other.

The parser's job is to reassemble those fragments into reading order, then guess what each block means. It does this with a mix of positional heuristics and pattern matching: text at the top in a larger size is probably a name, a line matching a date pattern near a job title is probably an employment period, a short all-caps line is probably a section heading.

Every formatting rule you have been told follows from this.

Two columns

You see a sidebar with your skills and a main column with your experience. The parser sees text fragments at various x-positions, and its reading-order algorithm goes left to right, top to bottom.

The result is interleaving. Your resume becomes:

Skills                  Experience
Python                  Senior Analyst, Acme
SQL                     2021 - Present
Tableau                 Built dashboards for

...read as Skills Experience Python Senior Analyst, Acme SQL 2021 - Present Tableau Built dashboards for. The dates now sit next to "SQL". The job title is glued to a skill. Nothing parses.

Some modern parsers detect columns correctly. Many do not, and you have no way of knowing which one is on the other end of the application form. The cost of a single column is that your resume looks slightly more ordinary. The cost of two columns is that it sometimes becomes unreadable. That is not a close trade.

Tables

Same problem, worse. Table cell boundaries frequently do not survive text extraction, so a two-column table of Skill | Years collapses into an unpunctuated run of words.

Headers and footers

Many parsers deliberately discard the header and footer region of a page, because in most documents that region holds page numbers and document titles, which are noise.

If your name, email, and phone number are in the page header — as they are in a lot of templates, especially ones exported from design tools — they can be dropped entirely. You end up as an anonymous record with a good work history and no way to contact you.

Put contact details in the body of the page. It looks nearly identical and survives.

Icons and decorative bullets

That little envelope glyph before your email is usually a character from an icon font. Extracted as text it becomes an unrelated Unicode character, or a private-use codepoint that renders as nothing.

Worse, some parsers use the ratio of unusual characters as a signal that extraction has gone wrong. Load your resume with decorative glyphs and you can look like a corrupted file.

Dates

Jan 2021 – Present parses. 01.21 – now often does not. 2021-2023 for one role and March '23 onwards for the next means the parser gets one and misses the other, and your total experience is computed from whatever survived.

Pick one format and use it everywhere. The en-dash is fine; the inconsistency is what hurts.

Scanned or image PDFs

If your resume is an image — exported from a design tool as a flattened graphic, or scanned from a printout — there is no text layer at all. Extraction returns nothing. Some systems run OCR, most do not.

This is the one genuinely fatal formatting error, and it is invisible to you because the file looks perfect on screen. Open your PDF and try to select a line of text with your cursor. If you can't, no ATS can read a word of it.

The part nobody mentions: keywords count, but only true ones

Once your resume is parsed, it is compared against the job description. Much of that comparison really is keyword matching. Recruiters search their ATS for the skills and tools in the job post, and a resume that never uses the job's words for something you did is easy to miss — even when you did it.

That is where most "ATS optimisation" advice goes wrong: stuff the job's keywords into your skills line, ideally in white text. Two problems. First, white-text keyword stuffing has been detectable for over a decade and is treated as fraud when found. Second, repeating a word doesn't make you a better match. The recruiter who opens your resume reads the bullets, and a skill named nowhere in your work looks exactly like what it is.

So the winning move is to name your real work in the job's words, in the bullet where you actually did it:

Ran weekly reviews with engineering, design, and risk to agree the quarterly roadmap

...becomes

Led stakeholder management across engineering, design, and risk, running weekly reviews to agree the quarterly roadmap

Same fact. Now an ATS search for "stakeholder management" finds it, a recruiter can see where you did it, and you can talk about it in the interview. Then list the skills you genuinely have in your Skills section, using the job's spelling. The ones you don't have stay off.

A short, honest checklist

1. Single column. No tables, no text boxes.
2. Contact details in the body, not the page header.
3. Standard section headings: Summary, Experience, Education, Skills.
4. One consistent date format, on every role.
5. Real text, not an image. Check by selecting text in your PDF.
6. Literal • bullets. No icon fonts.
7. Use the job's words for work you really did — in the bullet, not just in a list.

Where this leaves you

Formatting is necessary and not sufficient. A perfectly parseable resume that never names what the job asks for still ranks badly — it just ranks badly for an honest reason, which at least you can act on.

That is the split worth holding on to. Some of the distance between you and a role is presentational, and fixing it is pure gain. Some of it is real, and no amount of formatting closes it.

Jiffy CV separates those two for you against a specific job description: which of the job's skills are already on your resume, which are in your work but not your words, and which are genuinely missing. Run a free scan and see which is which for your own resume.