# How ATS systems read your CV (and what breaks them)

> What actually happens after you hit apply: how parsers turn your file into searchable text, the formatting that scrambles it, and how to check yours in seconds.

_Category: Winning the application · Updated: 2026-10-17 · 5 min read_

Most applications are read by software before a human sees them. Understanding that machine is not about gaming it; it is about not being thrown away for reasons you cannot see.

An Applicant Tracking System (ATS) is the software a company uses to receive, store, search and rank applications. Nearly every large company, and most small ones, run one. When you hit apply, your CV does not land in a neat inbox. It is parsed into plain text and structured fields, stored in a database, and searched and filtered by recruiters.

## What actually happens to your file

There are four stages, and each one can lose something:

1. **Upload.** The ATS accepts a file, usually PDF, DOCX or plain text.
2. **Extraction.** A parser pulls the text out. It is looking for characters, not layout.
3. **Structuring.** It tries to map that text into fields: name, contact details, work history, dates, education, skills.
4. **Matching and ranking.** Recruiters search the database by keyword, title or company, and sometimes run automated scoring against the job description.

The human only ever reads what survives those steps.

## Parsers read text, not design

A parser does not see your two columns, your colour-coded sidebar or your skill bars. It sees a stream of text in whatever order the file provides. Design that looks great on screen can reorder, merge or drop your content entirely.

The traps that cause the most damage:

- **Multi-column layouts.** A single-stream parser reads across the columns, so two side-by-side blocks can interleave line by line into nonsense.
- **Tables and text boxes.** Content inside them is frequently dropped or detached from its heading.
- **Headers and footers.** Many parsers ignore them, which is exactly where people put their phone number and email.
- **Images, icons and skill bars.** Anything drawn as a graphic is invisible. "5/5 Python" as a dot chart says nothing.
- **Creative section headings.** "My journey" is not "Experience"; the parser may not recognise the section at all.
- **Unusual fonts and outlined text.** If the text is saved as vector outlines, there are no characters to extract.
- **Inconsistent dates.** "Jan 2020", "01/2020" and "2020" mixed together are hard to normalise into a timeline.

None of this is about aesthetics. It is about whether the machine can recover your information.

## Keywords: matching, not stuffing

Once your CV is text, much of the filtering is keyword-based. A recruiter searching "Kubernetes" will only find people whose CV contains that word, and some systems score CVs against the job description.

The honest way to win this:

- **Mirror the job's vocabulary.** If they say "PostgreSQL", do not only write "Postgres"; use their term where it is truthful.
- **Spell out acronyms once.** "Continuous integration (CI)" catches both searches.
- **Put skills where they are searchable.** A skills line is fine, but weaving the terms into your experience bullets is stronger.
- **Do not keyword-stuff.** Modern systems and human reviewers both punish a wall of disconnected terms, and a white-text keyword block is an instant credibility loss.

## What the ATS does not do

The ATS rarely rejects you on its own. It is a filing cabinet with a search box. The decisions come from a recruiter filtering that database, or from crude automated rules a hiring manager set up, such as "only candidates with a degree", that have nothing to do with your ability.

That is exactly why parsing matters so much: a perfectly qualified candidate with an unreadable CV is invisible in the search results.

## A pre-flight checklist

Before you send, confirm:

- The file is **PDF** (or the format the posting asks for), exported from a text-based source rather than a scan.
- One **single-column** layout, with no tables and no text boxes.
- Contact details are in the **body**, not a header or footer.
- Section headings are the **standard** ones: Summary, Experience, Education, Skills.
- Dates use **one consistent format**, with an end date or "Present".
- LinkedIn and GitHub are written as **full URLs** in the text, not hidden behind linked words.
- You can **select and copy** the text in your PDF. If you cannot, a parser cannot either.

## Test it in seconds

Reading your own CV the way a parser does is genuinely hard to do by eye, which is why we built a free checker. [Scan your CV with the ATS Resume Checker](/ats-resume-checker) and it will show you the exact text an ATS extracts, flag multi-column and interleaving problems, check the essentials, and show the keywords a role expects that you are missing. It runs entirely in your browser, so your CV is never uploaded or stored.

Then tighten the writing itself with [how to write a developer CV](/guides/how-to-write-a-developer-cv), and read the listing before you apply with [how to read a job listing like a recruiter](/guides/how-to-read-a-job-listing-like-a-recruiter).