How to Make an ATS-Friendly CV

The four risks that actually matter

Four layout choices put the structure of your document at risk. We are describing what each one does to a document, not reporting how often any particular system fails on it, because that is the part nobody can tell you:

• Multiple columns. Text in a PDF has an order, and that order is not always the one your eye follows. Where two columns sit side by side, a job title from the left can end up adjacent to a skill from the right, and what gets stored is a sentence you never wrote. We used to call this the single most common cause of a badly parsed CV; we have no measurement that would support "most", so what we will say is that it is the risk with the worst consequences, because it corrupts the employment history rather than losing a field.
• Content in headers and footers. These are a separate region of the file from the body, and treating them as optional furniture is a reasonable thing for software to do — which is why contact details in a header is the version of this mistake that costs you the job rather than a line of formatting.
• Text inside images, text boxes or graphics. A skills chart, a logo containing your name, a profile rendered as a graphic — this one is not a probability at all. There is no text in an image to extract, so it is invisible to parsing and to a screen reader alike.
• Tables used for layout. A table is a grid, and flattening a grid back into a sequence of lines can be done several defensible ways. You do not get to choose which one is applied to your file.

Myths worth ignoring

Each of these is a claim somebody has made at you. The second column is what is actually knowable about it.

• "You must use Arial or Times New Roman." A PDF that embeds its fonts and contains real text does not care what the typeface is. The thing worth checking is that the text is there at all, which the test below does in ten seconds.
• "Never use a PDF." PDF has been the standard document-exchange format for job applications for a long time, and the format itself carries extractable text when it is generated properly. Send a PDF unless the application asks for a Word document — and if it asks, send what it asks for, because that instruction is the one piece of evidence you have about the receiving system.
• "Keyword stuffing in white text works." Set aside whether software notices. A human opens the file, and a block of invisible terms is read as an attempt to mislead rather than as a formatting quirk. That is the reason not to do it, and it does not need a claim about detection to hold.
• "You get scored out of 100 and rejected below a threshold." Some systems do produce a match score for the recruiter. A score presented to a person is a sorting aid; whether any given employer has configured it as a gate is a question about that employer, not about the software.
• "Never use bullet points." Standard bullet characters are ordinary text. Decorative glyphs and emoji are a different matter, because what they are in the file is not always what they look like on the page.

What to do instead

1. Use a single column for the whole document.
2. Put your contact details in the body of the page, at the top, not in a header.
3. Use conventional section headings: "Work Experience", "Education", "Skills". Software that has to decide which block of text is your employment history has to recognise the heading above it somehow, and the conventional words are the ones most likely to be on any list. "Where I have been" is charming, and it is charming to a human reader who has already decided to read the page.
4. Write dates in a consistent, unambiguous format — "March 2022 – Present" throughout, not a mix of formats.
5. Keep the job title, employer and dates on separate, clearly structured lines rather than run together in a sentence.
6. Export as a PDF with embedded fonts and selectable text. Open it afterwards and try to select the text with your cursor: if you cannot, neither can the parser.
7. Include the exact terms the advert uses, where they are true of you. If it says "stakeholder management", use that phrase rather than a synonym.

The selectable-text test

This takes ten seconds and catches most serious problems. Open your exported PDF, select all, and copy. Paste into a plain text editor.

If your name, phone number, job titles and dates all appear in a sensible order, your CV will parse. If the text comes out interleaved, in the wrong order, or missing entirely, you have found the problem before an employer did.

What a parser-safe layout actually looks like

The list above is easier to follow with something to look at. Below is the Minimal ATS layout from this site, rendered by the same code that produces the downloaded PDF.

It is deliberately plain: one column, contact details in the body rather than a header, conventional section headings, dates in a consistent format, and no tables, graphics or text boxes anywhere. Nothing about it is clever, which is the point — every decision on the page is one fewer thing a parser can get wrong.

When a designed CV is fine

Not every application goes through a tracking system. Small companies, direct applications to a named hiring manager, referrals, agencies that work from email, and most creative roles never involve one.

Keeping two versions is a reasonable strategy: a strict single-column version for portals, and a designed version for direct applications. What is not reasonable is using a two-column design for a large employer's portal and hoping.

Every template in this site's gallery carries a label saying how well its structure suits automated parsing, and each template page says plainly when that layout is the wrong choice. A two-column or sidebar layout is not a worse document — it is a worse document to put through a portal, which is a different statement.