Skip to main content
CreateCVOnline

ATS

ATS CV: how applicant tracking systems actually read your CV

An honest, technical account of what happens to your file between the upload button and a recruiter's screen — what genuinely breaks parsing, what gets blamed for it unfairly, and why no builder can promise you a pass.

What an applicant tracking system actually is

An applicant tracking system is a database with a workflow attached. It holds requisitions, receives applications, moves candidates through stages, schedules interviews, stores notes and produces the reports the recruitment team is measured on. Parsing your CV is one small feature at the front of a much larger product, and it exists mainly to save a recruiter from typing your employment history into a form.

That framing matters, because the popular picture of an ATS as a gatekeeper that reads your CV and decides your fate is mostly wrong. Systems in wide use — Workday, Oracle Taleo, SAP SuccessFactors, iCIMS, Greenhouse, Lever, Ashby and Bullhorn among them — differ enormously in how they parse, but almost none of them scores your document and rejects it. Applications are eliminated in two much more mundane ways: knockout questions on the application form, which you answer yourself, and recruiter searches, which only surface candidates whose extracted text contains the terms being searched for.

So the goal is not to satisfy an algorithm. The goal is to make sure the text of your CV arrives in the database complete, in the right order and attached to the right fields — because you cannot be found in a search that never indexed your job titles.

What happens to your file after you press submit

  1. 1

    Upload and storage

    Your original file is kept intact. It is usually what a recruiter opens later, which is why the design still matters even in a parser-driven process.

  2. 2

    Text extraction

    The system pulls a stream of characters out of the file and reconstructs a reading order from where each glyph sits on the page.

  3. 3

    Section and field detection

    Headings split the stream into blocks, then employer, job title, dates, degree and institution are picked out of each block.

  4. 4

    Indexing and review

    The structured result lands in a searchable database. Many portals then show it to you and invite you to correct it before you submit.

Text extraction

A PDF does not store paragraphs, sentences or even words. It stores instructions to draw particular glyphs at particular coordinates, along with a font mapping that says which character each glyph represents. Extraction walks that list and reassembles a plausible reading order from position: text at the same vertical offset probably belongs to the same line, a large horizontal gap probably means a new column, a change in vertical spacing probably means a new paragraph. Every one of those inferences is a guess that a complicated layout can defeat. A Word file is easier because it carries a real document structure, but it introduces its own hazards in text boxes and floating shapes.

Section detection

With a character stream in hand, the parser looks for headings and cuts the document into blocks. It works from a dictionary of known headings and their synonyms, sometimes reinforced by formatting cues — a short line in bold, in a larger size, with space above it, is probably a heading. This is the single most fragile stage in the pipeline and the easiest to protect, because it depends almost entirely on your using words the parser has seen before.

Field extraction and date normalisation

Inside an experience block, the parser tries to identify the job title, the employer, the location and the start and end dates for each role, then normalises those dates into a machine-readable range. This is where tenure comes from, and tenure feeds directly into the filters recruiters apply — five years in the field, currently employed, three years in the last role. A date it cannot read becomes a blank, and a blank tenure can drop you out of a filtered list without anybody having formed an opinion about you.

Indexing and the review screen

The parsed result is written into the candidate record and indexed for search. Plenty of portals then show you what they extracted and ask you to check it — the step everybody resents, where you re-enter three jobs the system just read. Do not skip it. The fields on that screen, not your original file, are what the recruiter filters on, and it is your only chance to see the parse of your own CV.

What genuinely breaks parsing

These are the failures worth designing around. Most of them produce a file that looks perfect to you and arrives empty or scrambled at the other end.

Text that lives inside an image

A CV exported as an image-only PDF, a scanned document, a name rendered as part of a logo, skill levels drawn as bars, an infographic timeline. To a text extractor there is nothing there at all. Some systems run OCR as a fallback; most do not, and the ones that do produce a rough approximation.

Contact details in the page header or footer

Several parsers treat the header and footer regions as page furniture and either drop them or append them somewhere unhelpful. The classic casualty is a beautifully designed CV that arrives in the database with no phone number and no email address. Keep contact details in the body of page one.

Tables used for layout

A table can be read column-first instead of row-first, and merged cells can concatenate two unrelated pieces of text into one line. A skills grid built as a table is a common way to end up with "Python Stakeholder management SQL Budgeting" in the indexed text. Ordinary paragraphs and line breaks are safer.

Multi-column reading order

Two columns are fine when the parser detects the gutter and reads each column in turn. They fail when a section wraps from one column into the other, when a heading spans both, or when the gap between them is too narrow to identify — at which point line one of the left column is joined to line one of the right.

Invented section headings

Section detection is largely dictionary-driven: the parser knows Experience, Work Experience, Professional Experience, Employment History and a few dozen synonyms. It does not know "Where I have been", "My toolkit" or "The story so far". An unrecognised heading usually means the block below it is never mapped to structured fields.

Fonts that do not extract cleanly

A PDF stores glyphs, not letters, and relies on an embedded mapping to say which character each glyph represents. When that mapping is missing or wrong — which happens with some subsetted and decorative fonts — the extracted text comes out as nonsense that looks perfect on screen.

PDFs from some design tools

Layout and illustration applications can export text as vector outlines, which turns every letter into a shape. The file looks flawless and contains zero extractable text. The same applies to a PDF exported with security restrictions that block content copying.

Dates a parser cannot normalise

Abbreviated years ("’19 – ’21"), seasons ("Spring 2020"), open-ended phrasing ("since 2018") and localised month names all risk producing a blank or wrong tenure. Since tenure feeds directly into search filters for years of experience, a mangled date can quietly exclude you from a shortlist.

What is fine, and is routinely over-claimed as a problem

A large amount of ATS advice is folklore repeated until it sounded like fact. These things are not the reason you were not called.

A modest accent colour

Colour is a rendering instruction. A text extractor never sees it. One accent colour on your headings is invisible to the parser and legible to the human who opens the file afterwards.

PDF, as a format

PDF is accepted and parsed by the systems in general use, and it is the only format that guarantees the recruiter sees the layout you built. The problem was never PDF; it was image-only PDFs and outlined text. Where a portal genuinely needs a Word file, it tells you so on the upload screen.

A clean two-column layout

Many current systems handle a well-separated sidebar without difficulty. Treat it as a small, managed risk rather than a disqualification: keep whole sections inside one column, leave a generous gutter, and keep a single-column version for portals you do not recognise.

Bold, italics and small caps

Emphasis is styling on ordinary text and extracts as ordinary text. Bold job titles and italic employer names cost nothing and make the document far quicker for a person to skim.

A second page

Page count is meaningless to a parser, which sees one continuous stream. Length is a question about the reader, not the software — and outside the United States, two pages is the norm rather than an indulgence.

Grouped skills and standard bullets

Skills organised under category labels parse fine and read better. Ordinary bullet characters are fine too; the ones that cause trouble are decorative glyphs from symbol fonts, which can extract as stray characters mid-line.

An honest note about ATS scores — including ours

An ATS score is a heuristic, not a certification

Every template on CreateCVOnline carries a score from one to five. It is calculated from properties of the layout we can inspect — column count, whether any text is rendered as graphics, whether the section headings are conventional, whether contact details sit in the document body. It is not the output of a test against real applicant tracking systems, because such a test is not something any builder can honestly offer.

There is no standard to certify against. Dozens of vendors each ship their own parser, each on its own release cycle, and large employers configure them differently on top of that. The same file can be read perfectly by one system and clumsily by another, and by the same system differently after an update. Any product — this one included — that promises your CV will pass every ATS is selling you a certainty that does not exist.

What can be said honestly is narrower and still useful: a single-column document made of real text, with conventional headings, no graphics carrying information and no content in the page margins, is the lowest-risk file you can upload anywhere. Every template we score five has those properties. That is a statement about the design, and it is the only kind of statement that is defensible.

Treat any score — ours, a checker’s, a recruiter’s browser extension’s — as a smoke alarm rather than a building inspection. It is worth listening to when it goes off, and it is not evidence that the house is safe.

The checklist, before you press submit

Ten checks, none of which takes longer than a minute. The first one catches most of the serious failures on its own.
  1. 1Open your exported PDF, select all, copy, and paste into a plain text editor. If any text is missing, scrambled or out of order, no parser will do better.
  2. 2Contact details sit in the body of page one, never in the page header.
  3. 3Section headings are conventional: Summary, Experience, Education, Skills, Certifications.
  4. 4Every role gives job title, employer, location and a date range as ordinary text lines.
  5. 5Dates use one consistent format throughout, with months as well as years.
  6. 6No text is trapped inside an image, icon, chart, logo or skill bar.
  7. 7No tables, no text boxes, no content in the margins.
  8. 8One column, unless you have a specific reason and a single-column backup.
  9. 9The file is named with your actual name, and exported without security restrictions.
  10. 10Where the portal shows you what it parsed, you read it and fixed the fields it got wrong.

23 templates scored 5 out of 5

Single-column reading order, conventional headings, contact details in the document body, and no text rendered as graphics. These are the lowest-risk layouts in the gallery.

Modern ATS

modern · one column

Free

Modern Clean

modern · one column

Free

Modern Minimal

modern · one column

Free

Modern Professional

modern · one column

Free

Business Professional

corporate · one column

Free

Finance CV

corporate · one column

Pro

Operations CV

corporate · one column

Pro

IT Professional

technology · one column

Pro

Software Engineer

technology · one column

Free

Tech Minimal

technology · one column

Free

Academic CV

classic · one column

Pro

Classic Professional

classic · one column

Free

Government CV

classic · one column

Pro

Legal CV

classic · one column

Pro

Simple Classic

classic · one column

Free

Timeless

classic · one column

Pro

Traditional CV

classic · one column

Free

Accountant CV

ATS-friendly · one column

Pro

ATS CV

ATS-friendly · one column

Free

Entry-Level Resume

ATS-friendly · one column

Free

ATS Resume

ATS-friendly · one column

Free

ATS Simple

ATS-friendly · one column

Free

Student CV

ATS-friendly · one column

Free

Frequently asked questions

The technical questions people ask about parsing, scoring and testing.

Almost never on the basis of parsing quality. The widely repeated claim that three quarters of applications are auto-rejected before a human sees them is far more often quoted than sourced. What does filter people out is the application form: knockout questions about work authorisation, licences, location, notice period and minimum years of experience are answered by you, not extracted from your file, and they are frequently configured to reject automatically. The second filter is the recruiter, who searches the database and only ever sees the candidates whose extracted text matched the search.