How we test a layout for ATS compatibility

Every layout in the library carries an ATS badge. On its own, a badge means nothing. Here is what we actually check before a layout goes live.

An ATS doesn’t ‘see’ a layout, it reads a stream of text

An applicant tracking system (ATS) doesn’t look at a CV the way a person does. It doesn’t notice columns, colours or the size of headings. It receives a stream of text extracted from the PDF, in a specific order, and that order decides whether your jobs are matched to the right dates, whether your current role is identified as the most recent and whether your skills end up mixed in with your education. The same applies when you apply through a recruitment agency: agency systems also parse the CV to fill in the candidate’s record.

So the question is never ‘does this CV look nice’. It’s ‘in what order does the text come out once a machine opens the PDF’.

What we tested, and how

Before we launched the layout library, we checked a principle that is simple to state but rarely verified: a single-column layout, even a strongly styled one (colour bands, a bold heading font, a clear hierarchy), keeps the extraction order intact.

The method: raw text extraction (pdftotext or equivalent) on the generated PDF, then a check that the order follows the logic of the CV (name, contact details, personal statement, work experience from most recent to oldest, education, skills) with no block jumping out of place and no content lost. The test was run on two different rendering engines (wkhtmltopdf and Chromium via Playwright), with the same result both times.

We also tested, and ruled out, an approach that often comes up in advice online: using the CSS order property in a flexbox layout to display elements in a visual order different from the order of the code. The idea is to keep a ‘clean’ order for the ATS while rearranging the display for the human eye. On both engines tested, it doesn’t work: the text in the PDF follows the visual rendering order, never the order of the source code. A CV relying on this trick would pass the wrong order to the ATS, however it looks on screen.

What this changes in practice

This test has a direct effect on what we consider ‘allowed’ in a layout. The real constraint isn’t ‘keep it plain’. It’s ‘stay in a single column, with a code order that matches the intended reading order’. Within that constraint, a very large name at the top of the page, a heavy heading weight or a colour band cause no extraction problem: they’re typographic choices, not structural ones.

That’s the distinction most guides on the subject don’t make. They treat a simple structure and a plain appearance as one and the same rule, when only the first really determines how an ATS reads the CV.

Two-column layouts

A two-column layout isn’t necessarily unreadable for an ATS, but it depends far more on the parsing engine the recruiter uses: some handle the reading order correctly, others mix the columns up. Without validation against an advanced parsing engine on top of raw extraction, we can’t claim that a two-column layout is reliable everywhere. That’s why we distinguish two levels of proof rather than claiming universal compatibility: a single-column structure validated by raw extraction, which is what every current layout uses, and, for any future two-column layout, a further test against an advanced parsing engine.

Why we publish this

Most sources on CVs and ATS claim compatibility without explaining how it was checked. Some even put forward precise percentages (failure rates, accuracy rates) without giving the method or the sample behind them. A figure you can’t trace back proves nothing.

What we describe here can be checked: anyone can take a PDF, run a raw text extraction on it and see whether the order makes sense. The copy-and-paste test that UK careers advice often suggests (paste your CV into a plain-text document and see what’s missing or out of order) is a rough version of the same idea. We run this same test automatically on every CV you generate.