How to write a CV an ATS can actually read

What actually breaks parsing

The failure is almost never the wording. It is that the parser could not find the text, or found it in an order that made no sense.

• Text inside images. A CV exported as a picture — or a name rendered as a logo — is invisible to the parser. If you cannot select the text in a PDF viewer, neither can the ATS.
• Multi-column layouts. Two columns look elegant and read cleanly to a human, but many parsers walk the document in its underlying order rather than visually. A sidebar can end up interleaved line by line with the main column.
• Tables used for layout. A table holding dates in one cell and roles in another frequently comes out as one long run of cells with the relationship lost.
• Headers and footers. Contact details placed in a page header are commonly dropped, because that region is not part of the document body.
• Unusual section names. “My journey so far” is charming; the parser is looking for “Experience”.
• Non-embedded fonts. If the font is not embedded, text can be rendered as glyph outlines with no character codes behind it — visually perfect and entirely unreadable.

What doesn't matter as much as people think

A large amount of ATS advice is folklore. These are the ones worth ignoring:

• Colour and design. Colour is not the problem. Structure is. A well-structured CV with an accent colour parses exactly as well as a black-and-white one.
• One page versus two. No parser rejects a second page. Length is a human judgement, not a machine one.
• Plain .txt files. A text-based PDF parses reliably and looks like a professional document. You do not need to sacrifice one for the other.
• Exact keyword counts. Stuffing a term ten times does not multiply your score, and the human who reads it next will notice.

The formatting rules that do the work

• One reading order: name and contact details first, then a short profile, then experience newest first, then education and skills.
• Standard section headings, spelled the ordinary way.
• Dates in a consistent format, on the same line as the role they belong to.
• Job title, employer and dates as real text, not as an image or an icon.
• Links written out as real links — an email address that is clickable and a profile URL that is visible.
• Export to PDF with fonts embedded, and check that you can select the text afterwards.

A quick test: open your exported PDF, select all, and paste into a plain text editor. What you see is roughly what the ATS sees. If your job titles have drifted away from their dates, or half the page is missing, fix that before you fix your wording.

Keywords, honestly

Screening often does look for terms from the job description, so it matters that the words on your CV match the vocabulary of the role. That is not the same as keyword stuffing. If the posting says “incident response” and your CV says “on-call firefighting”, the words differ but the work does not — and the machine only sees the words.

The honest version of this is to describe the same real experience in the language the industry uses for it. Rewriting per application is tedious by hand, which is exactly why most people send one generic CV to forty roles.

How SuitedCV handles this

Every SuitedCV template exports a text-based PDF with embedded fonts, one reading order, and live links — the constraints above are built into the templates rather than left to you. The on-screen preview and the exported file come from the same renderer, so what you approve is what the parser receives.

For the vocabulary problem, you keep one master CV and create a tailored version per application. The tailoring proposes changes field by field against the job description, and you keep or skip each one, so the language moves toward the role without anything being invented.

Common questions