The Formatting Rules That Matter and the Ones That Do Not
Most formatting advice defends against a parser failure that rarely happens. What genuinely helps, and what you have been told to fear for no reason.
Formatting advice for CVs is unusually confident and unusually unsourced. Do not use tables. Never use two columns. Avoid headers. One specific font. For an employer-side overview of computer activity records, see this overview.
Most of it defends against a failure mode that comes from a small number of legacy systems, and it has produced a generation of CVs optimised against a machine while being harder for a person to read. For an independent public reference, consult Europass CV guidance.
Where the fear came from
Some older systems used optical character recognition to generate an HTML preview of an uploaded CV. A recruiter who relied on that preview rather than opening the original file could see a perfectly good document rendered as garbage. Job seekers noticed and began searching for how to get past the software, and an industry formed around the answer.
Recruiters can open your original uploaded file.
So the risk is real and much narrower than the advice implies: poor parsing makes you harder to find in a keyword search, and it does not cause automatic rejection. See what applicant tracking systems actually do.
What genuinely helps
Standard section headings. "Experience", "Education", "Skills". Parsers look for them, and so does a person scanning. Creative headings — "My Journey", "What I Bring" — make both jobs harder for no gain.
Dates in a consistent, unambiguous format. Month and year, same style throughout. This is the field most commonly mangled, and gaps that appear because of inconsistent formatting look like gaps you have.
Real text, not an image. A CV exported as a picture, or with the header as a graphic, loses everything in it. Your name and contact details in an image is the version of this that actually costs people interviews.
Contact details in the body, not in the page header or footer, which some parsers skip.
A file format the employer asked for. Where nothing is specified, PDF preserves your layout and parses acceptably in current systems. Where a system specifically requests .docx, give it .docx.
A sensible file name. Firstname-Lastname-CV.pdf. It is what appears in the recruiter's file list.
One column for the main content. Not because two columns break parsing in most current systems, but because reading order in a two-column layout is ambiguous to both parsers and skim-readers.
What does not matter as much as you were told
Tables. Modern parsers handle simple tables. Complex nested tables are still a poor idea, mostly because they are hard to edit and hard to read.
Font choice, within reason. No parser rejects Calibri. Use something legible at 10–11pt.
Colour, used lightly. A restrained accent colour is fine and always has been.
Bullet characters.
A photograph — this is a market question rather than a parsing one. Standard in parts of Europe and Asia, avoided in the US and UK where it raises discrimination concerns. See what differs by market.
"ATS-friendly templates". Most are ordinary layouts sold with fear attached, and some are worse than what you had because they strip readability in the name of parseability.
Never do this
White text or hidden keywords. Text coloured to match the background, or set to a tiny size, containing keywords for the parser to find. Recruiters find it — it appears in the parsed text and in a plain-text view — and the reaction is that you attempted to deceive them, because you did.
Keyword blocks with no context. A list of forty technologies you have "experience with" is transparent and it dilutes the ones you actually know.
Anything the reader cannot see but the parser can. The principle covers cases that have not been invented yet.
The test that settles it
Save your CV as plain text and read what comes out.
Most PDF readers and word processors will do this in one step. What you see is close to what a parser extracts.
If your name is missing, your dates are scrambled, or the sections are interleaved, fix the layout. If it reads sensibly, your formatting is fine, whatever a scoring tool tells you.
Then read the original as a person would, on a phone, for thirty seconds. That is the test that actually determines what happens, because the constraint is a recruiter with four hundred applications rather than a parser. See what applicant tracking systems actually do.
Formatting for the person, which is the point
Once parsing is handled, everything else is about the thirty seconds.
Most important content in the top third. Recruiters scan from the top and stop.
White space. A dense CV is not read; it is skimmed and abandoned. Two pages with air beats one page packed.
Consistent visual hierarchy, so the eye can find job titles and dates without hunting.
Short bullets. Three lines is a paragraph, and paragraphs are skipped.
Reverse chronological, unless you have a specific reason. It is what readers expect and deviation costs attention.
And a length that suits your experience. See one page, two pages.
The short version
The parsing risk is being hard to find, not being rejected. Recruiters can open your original file.
What helps: standard headings, consistent dates, real text, contact details in the body, one column, a sensible file name.
What matters less than claimed: tables, fonts, colour, bullet characters, "ATS templates".
Never hide text. It is visible in the parsed output and it reads as an attempt to deceive.
Save as plain text and read it. That single check replaces every scoring tool in this category.