What an ATS parser actually does to your CV file

"We couldn't read your file", and what that sentence is actually reporting

You spend an evening on a CV. It is clean, it fits on two pages, the spacing is right, and you are, for once, a little proud of it. You upload it and either nothing happens for three weeks or you get a line back saying the file could not be read. There is no diagnostic, no highlighted section, no hint at which part failed. That silence is the whole problem, because the thing that went wrong is completely knowable and nobody tells you.

A parser does not read your CV the way you see it. It extracts a linear text stream from the file and tries to map that stream onto database fields, so anything whose meaning lives in the layout rather than in the text order can be reordered, merged into a neighbouring field, or dropped.

The literal error message is narrower than people assume. It covers a short list of causes, all of them in the file itself: a scanned or image-only PDF with an empty text layer, a document that is password-protected or export-restricted, a file whose extension does not match what is inside it, or something the upload form simply does not accept. It is a read failure at the level of bytes. It has not looked at your experience and found it wanting.

One boundary before we go further, because two different questions get mixed together constantly. This page is about how the file itself breaks on the way in. Whether an automated system then filters you out on the content is a separate argument, and I made it in the piece on whether an ATS auto-rejects CVs. I am not going to restate it here.

And the concession, up front rather than buried at the end, because it is the strongest objection to the entire page. You should not have to design your CV around software that cannot read a two-column layout. That is an engineering failure on the vendor side, not a candidate failure. Someone who lost a callback to a reading-order bug did nothing wrong, and nobody should have to learn document internals to apply for a job. I am writing the page anyway, for one narrow reason: knowing costs you nothing, and the rejection email is never going to tell you.

Your CV is a picture. The parser wants a database row.

A PDF stores glyphs at coordinates, not structure. That single sentence explains most of what follows, so here is what it means in plain terms. A PDF page is a set of drawing instructions: put this character, in this font, at this x and y position on the page. It does not say "this is a heading", "this is a table cell", "this block is the sidebar". Unless the file carries an accessibility tag tree, which most CVs exported from a design tool do not, that information exists only in your eyes.

So an extractor has to reconstruct it by inference. It groups glyphs into words by looking at the gaps between them, groups words into lines by their shared baseline, and groups lines into blocks by proximity. Each of those steps is a guess that is right most of the time. Every failure further down this page is one of those guesses going wrong on a layout that made the guess hard.

A DOCX is a different animal. Underneath, it is a zip of XML in which a paragraph is a paragraph element, a table is a table element, and a heading carries a named style. The structure is stated rather than inferred. That does not mean you should always send Word. Plenty of parsers handle PDF perfectly well, a PDF looks the same on every machine and a Word file does not, and quite a few employers accept only one of the two. Follow the posting's instruction first, always. What is true is narrower: a DOCX hands the parser structure it would otherwise have to guess at.

The other half of the job is mapping. Once there is a text stream, the system tries to fill in fields. These are the ones that matter, and every failure mode below is a failure of one of them.

• Name
• Contact details: email, phone, location
• Employer, per role
• Job title, per role
• Start date and end date, per role
• Skills
• Education and qualifications

You have already seen the output of this mapping without being told that is what it was. When an application form makes you upload the file and then re-type the same three jobs into boxes, the boxes that arrived pre-filled are the mapping showing its work, and the boxes that arrived wrong are it failing in front of you. Whether that step means a human is checking anything is a different question, and I answered it in the piece on uploading your CV and then filling out the form anyway.

"The sidebar gets read in the middle of your work history"

That line is from a practitioner posting on r/resumes who said they parse CVs professionally and described what broke across a sample of 3,835 files they had processed. I will come back to how much weight that figure can carry. The sentence itself needs no sample to stand up, because it follows directly from how reading order gets reconstructed, and it is the single most expensive failure on this page.

Picture the layout almost every modern template ships: a narrow left column with skills and languages, a wide right column with your work history. On screen the two columns are obviously separate. In the file they are just glyphs at coordinates, and glyphs in the left column sit on the same horizontal baselines as glyphs in the right column. An extractor that groups by line, rather than detecting the column boundary first, will emit them together.

Read the second block as a machine would. The line that should carry your job title now reads "Python Financial Controller". A field mapper looking for a title on that line gets a title with a programming language welded to the front of it. Your skills are no longer a list, they are the first word of four unrelated lines. And if the extractor instead groups by block and drops the sidebar in wherever proximity suggests, the skills column can land between two jobs, so the dates that follow it attach to the wrong role. That is the mechanism behind a CV that shows the right ten years of experience on screen and the wrong ones in the database.

The honest caveat: plenty of parsers do detect columns correctly, and I cannot tell you in advance which one is on the other end of any given upload. So the advice is not "two columns will destroy you". It is narrower and more defensible. A single-column layout removes the ambiguity instead of betting on it being resolved well. You lose nothing that a recruiter values, because nobody has ever been hired for a sidebar.

Flattened tables, skill blobs, and damage at the character level

The second reported failure from that same thread was a skills section flattened into one blob, and tables are usually the cause. A table gives the reader meaning through the grid: this cell pairs with that cell. In an extracted stream the cell boundaries are gone, and what is left is a run of words in whatever order the cells were walked.

Every pairing is now guesswork, and it gets worse downstream. Skill matching generally works by looking for known terms in the text. A term that has been fused into a longer string, or split across what the extractor thinks is a line break, may simply not be found. You had the skill on the page. The lookup did not see it, and nothing anywhere reports that.

Then there is the character level, which is the part almost nobody writes about. Custom bullet glyphs from an icon font often come out as an unmapped character or as nothing at all. Ligatures are the sharpest example, and I know this one first-hand because it cost me a week on careerify's own PDF extractor. A ligature is one glyph that draws two characters at once, the way many fonts draw fi as a single shape. In one common Windows font, our extractor handed that glyph back as a null character, so the word arrived with a hole in the middle. On screen the CV was flawless. In the extracted stream a word was broken, and nothing in the file announced it.

Almost everything on this page is invisible from your side. The file looks correct because you are looking at the drawing. The parser is looking at the instructions.

The parts of your CV the parser may never see

Reading order and tables scramble what is there. This section is about content that does not make it into the stream at all, which is worse, because a scrambled field can still be found by a human skimming and a missing one cannot.

Dates deserve one extra line because they are the quietest of the six. Your career history is a sequence of ranges, and the parser has to work out where each range begins, where it ends, and which employer it belongs to. Give it a month and a four-digit year, use the same format for every role, and use the same separator throughout. It reads as fussy. It is the cheapest fix on this page.

The mirror image of everything here is text that is present in the file but invisible on the page, which is exactly what the white-text keyword trick relies on. It is a bad idea for reasons that have nothing to do with parsing, and I set them out in the piece on the invisible prompt hack. Everything I recommend on this page changes the container, never the claims.

Different systems, different parsers, and how much the numbers can carry

Workday, Greenhouse, Taleo and Lever are distinct products with distinct parsers, and here is where I have to disappoint anyone who came looking for a table of vendor behaviour. I cannot tell you what any of them does internally. I have not tested them, their behaviour changes between versions and between customer configurations, and every confident public claim about a specific vendor's parser I have chased turned out to have no method behind it. Anyone selling you a per-vendor rulebook is guessing. What is safe to say is what makes them the same kind of product: each one has to turn a CV file into a stored record, which means extracting text and mapping it onto fields. How well any of them handles the hard cases described above, I cannot tell you.

That is also the honest answer to "which format is safest". There is no format, template or layout that guarantees a clean parse anywhere. There are only choices that leave less to be inferred. I would rather give you that than a rule I cannot defend.

Now the 3,835 figure, handled with the care it deserves. It is one person on Reddit, describing their own reported sample, in a thread where several commenters doubted the number was real. I am not going to launder it into "research shows", and I would rather you discounted it entirely than trusted it more than it can bear. Notice that nothing in the mechanism sections above depends on it. Reading order, flattened tables, empty text layers and unrecognised headings follow from how PDF and DOCX are built, and they would be exactly as true if that thread had never been posted. The sample tells you these failures are common. The file formats tell you why they happen.

One more thing worth stating rather than hiding, because it explains why the situation persists. From the employer side, a screening process that loses some good candidates is often treated as an acceptable cost of handling the volume. I am not going to be outraged about it here; I am telling you because it sets your expectations correctly. The fix is not going to arrive from the vendor in time to help your next application, which is why it has to happen on your file for now.

The product paragraph, once, so you can weigh it against everything above. careerify has a free check at the link below: no account, no card, three checks per IP address in 24 hours. It parses your real uploaded PDF or DOCX the way any other system would have to, then compares what it got against the advert you paste in, and shows you which of the advert's terms came through from your file and which did not. That is an inspection, not a fix. If a term you know is on page one comes back as missing, you have found one of the failures on this page. The rest of what careerify does, tailoring a stored master CV to a specific advert, is bounded by facts you entered yourself and cannot invent a role, an employer or a number you did not give it.