Will a designed CV pass an ATS?
Mostly yes, and the advice telling you otherwise is usually a decade old. An applicant tracking system does not look at your CV. It reads the text layer inside the PDF, which is a different thing from the page you see. Four things break that text layer, and only one of them is about how the page looks.
1. A CV that is secretly a picture
This is the real killer, and it is invisible. Plenty of CV builders render your page in a browser and screenshot it, then wrap the image in a PDF. It looks perfect. It opens correctly. It contains no text at all.
An ATS parsing that file gets nothing: no name, no employers, no dates. Some run OCR over it and produce a mangled approximation, which is arguably worse, because now there is bad data rather than obviously missing data.
Test it in five seconds. Open your PDF and try to select a line of text with your cursor. If you can highlight individual words, it is real text. If the whole page highlights as one block, or nothing highlights, it is an image. Ctrl+F for your own surname is the same test from the other direction.
A second tell is file size. A page of vector text is a few tens of kilobytes. The CVs this tool produces are around 5 KB. If yours is two megabytes, it is a picture.
2. Letter-spacing, which nobody warns you about
This one we found by measuring, and it surprised us. Designers love a tracked-out
heading: E X P E R I E N C E in small capitals with generous spacing
looks considered. Push that spacing past roughly a tenth of the font size and PDF
text extractors stop seeing a word.
The reason is mechanical. There are no spaces in a PDF. A text extractor infers word boundaries from the horizontal gap between glyphs. Once the gap inside a word is as large as the gap between words, the extractor splits every letter into its own word. Your heading comes out of the parser as nine one-letter words, and the section is no longer machine-readable.
We measured the threshold at about 0.09em using PDF.js, which is the extractor underneath a great many parsing pipelines. Our renderer caps letter-spacing at 0.08em and the test suite asserts that no heading ever extracts as spaced single letters. If you are building your CV somewhere else, set tracking modestly and then run the copy-paste test on the finished file.
3. Two columns, and the order they are written in
A sidebar is not automatically a problem. What matters is the order the text was written into the file, which has nothing to do with where it appears on the page.
A PDF's content stream is a sequence of drawing instructions. A parser that reads it in order gets whatever order the generator happened to use. Put the sidebar in first and the parser meets your skills list and contact details before it ever reaches your name, which is exactly the situation where a parser gives up and assigns your first skill as your job title.
LinkedIn's own PDF export has this shape, incidentally, which is one of several reasons it parses poorly. We wrote about what LinkedIn's export actually contains separately.
Our two-column layout writes name, then summary, then experience, and puts the side column last, while drawing it in the same visible position. The page looks identical either way. Only the parser can tell the difference, and it is the parser's opinion that matters here.
4. Fonts that cannot draw your name
The standard PDF fonts cover Latin script and nothing else. If your name is in Cyrillic, Greek, Chinese or Japanese and the generator has not embedded a font that contains those characters, the letters are silently dropped. You get a PDF with a gap where your name should be, and no warning that it happened.
Stroke and dotless letters trip up even Latin-alphabet names. Michał becomes Micha in a surprising number of tools, because the usual accent-folding trick has nothing to fold: the stroke through the l is part of the letter, not a mark on top of it. Đorđe loses two letters the same way. We handle those explicitly and refuse to generate a file we cannot render properly, rather than producing a quietly broken one.
What does not matter as much as people claim
- Tables. Modern parsers handle simple tabular layouts. Deeply nested tables used for page layout are still a bad idea, but a dates column is fine.
- Headers and footers. Worth avoiding for contact details, since some parsers ignore them, but not a disaster.
- Fancy fonts. Irrelevant to parsing, as long as the font is embedded and the text is real text. It matters to the human reading it afterwards.
- Colour. Parsers do not care. Printers and photocopiers do, so keep the contrast high.
- "Never use two columns." Too blunt. It is the write order that decides, not the visual arrangement.
The one test worth running
Open your finished PDF, select all, copy, and paste into a plain text editor. What you see is approximately what an ATS sees. If your name is at the top, your employers are in the right order, and no word has been shattered into letters, your CV parses. If it has not, no amount of keyword stuffing will save it.
linkedinto.cv renders vector text, orders the content stream for parsers, caps letter-spacing below the threshold above, and refuses to spend a download on a profile its fonts cannot draw. See what it produces, or read about fitting a long career onto one page.