← Guides

How an ATS actually reads your CV

The ATS isn't rejecting you — it's mis-reading you

"The ATS rejected my CV" is the most common explanation job seekers give for silence after applying, and it's usually not quite what happened. Applicant Tracking Systems — the software companies use to collect, store, and search applications — don't make yes/no hiring decisions. Their job is to parse your CV into structured fields (name, employer, dates, skills, education) so a recruiter can search and filter candidates later. A meaningful share of CVs that seem to vanish without a trace didn't get rejected by an algorithm's judgment — they got parsed badly, and the resulting garbled data is what a recruiter actually sees (or doesn't) when they search.

Who's actually running the pipeline

The 2026 market is concentrated: Greenhouse and Workday alone cover the large majority of top-rated employers, with Lever and the fast-growing Ashby picking up a meaningful slice of mid-market and startup hiring. Large enterprises lean on Workday, Oracle HCM, and SAP SuccessFactors; mid-market tech coalesces around Greenhouse and Lever. If you're applying broadly, your CV is being parsed by one of a fairly small number of parsing engines — which also means "ATS-friendly" formatting advice, done right, generalizes further than it might seem.

The five-stage pipeline

Every ATS parser runs roughly the same five stages, regardless of vendor:

  1. Text extraction — pulling raw text out of your file (PDF, DOCX, etc.).
  2. Tokenization — splitting that text into words and phrases.
  3. Sectioning — deciding which part of the document is "Experience," which is "Education," which is "Skills."
  4. Named-entity recognition — identifying specific things within a section: a company name, a job title, a date range, a technology.
  5. Structured output — writing the result into the ATS's own database fields.

Best-in-class parsers achieve around 87% field-level accuracy at the top end — meaning even a well-formatted CV, parsed by a good engine, has a real chance of losing or misplacing some fields. A poorly formatted one does much worse.

What actually breaks parsing

In order of how often they cause real damage:

  • Multi-column layouts. A visually appealing two-column CV (skills sidebar, experience in a main column) is read by most parsers left-to-right, line-by-line, across the whole page width — which means it interleaves your sidebar skills into the middle of your job descriptions. This is the single most common parsing failure.
  • Text inside images. A CV exported as a flattened image, or with a photo/graphic containing text, is often invisible to the parser entirely. If it isn't real, selectable text, assume the ATS can't read it.
  • Non-standard section headers. "Where I've Made an Impact" is a fine, human-friendly heading. A parser looking for "Experience" or "Work History" may not recognize it as the experience section at all, and file everything under it as unstructured text.
  • Tables for layout. Similar problem to multi-column layouts — a parser reading cell-by-cell can scramble the reading order.
  • Headers/footers for contact info. Some parsers skip header/footer regions entirely, which is exactly where a lot of templates put your name, email, and phone number.

None of this means your CV needs to be visually plain. It means the underlying document structure — the actual text flow, not just how it looks — needs to read in a sensible single-column order, with plain, standard section names, and every piece of contact information in the document body, not just decorative elements.

Open standards exist. Nobody uses them.

There have been several serious attempts at a standard, machine-readable CV data format — JSON Resume, HR Open Standards (LER-RS), Europass's own XML/EDCI format, Schema.org's JobPosting. Each is a real, usable specification. None has achieved meaningful adoption among the ATS vendors that actually process the bulk of applications — they remain useful for job boards, developer tooling, and credential wallets, but a CV submitted in JSON Resume format to a typical company's Greenhouse instance still goes through the same PDF/DOCX parsing pipeline as everything else. If you're hoping a standard format will let you skip formatting discipline, it won't yet.

What this means in practice

  • Single column, standard section names, real text (not images). This is the highest-leverage fix, full stop.
  • Put contact information in the main body, not just a header/footer or a graphic element.
  • Don't assume "ATS-friendly" means "boring." It means "parses correctly" — plenty of visually clean, single-column, well-labeled CVs look genuinely good.
  • When in doubt, check what the machine sees. Copy-pasting your CV's text into a plain text editor is a rough but honest approximation of what a parser extracts — if the result reads as a scrambled mess, so does what the ATS stores.

Related guides