Most formatting advice arrives as a list of commandments with no reasoning, which leaves you stuck the moment you hit a case the list does not cover. Every rule below comes with why it exists, so you can judge the edge cases yourself.
The rules that actually matter
| Rule | Why |
|---|---|
| Real text, never an image | A parser reads a text layer. A picture of text has none, so the document arrives blank. |
| One column | Columns share baselines, so a parser reads across them and interleaves your content. |
| Contact details in the body | Many parsers crop the page margins first, assuming they hold page numbers. |
| No tables for work history | Cells are read in an order set by the table structure, which rarely matches reading order. |
| Standard section headings | The parser files your history by matching heading text against a known list. |
| Dates as "Mar 2021 – Jun 2024" | Recruiters filter on length of experience. An unparsed timeline drops you from those filters. |
| Common fonts | An unusual embedded font can extract with the wrong characters, producing subtly wrong text. |
| Simple bullet characters | Decorative glyphs sometimes extract as junk that pollutes the text around them. |
What is fine, despite what you may have read
Bold and italics. They are font properties. The text extracts identically.
Bullet points. Standard bullets are fine and genuinely help a parser separate list items from prose.
Colour. Irrelevant. A parser reads text, not colour, with the single exception of white text on white, which is not a formatting choice but an attempt to hide keywords, and is a bad idea for other reasons.
A photograph. Parses fine, since it is simply ignored. Whether to include one is a question about local hiring convention and bias, not about software. In the US and UK, usually no. In much of continental Europe, expected.
Horizontal rules and section dividers. Fine. They contain no text.
Two pages. Fine for most experienced roles. Length is a human preference, not a parsing constraint.
The three that quietly cost people interviews
Skill rating bars
Four filled dots out of five next to "Python" conveys nothing to a parser, the rating is a drawing, so only the word survives. That is harmless in itself. What is not harmless is a skills section madeentirely of bars, where the proficiency was the whole point. Write it out: "Python, four years, data pipelines and analysis" says more and survives extraction.
Contact details in the header
This one is particularly cruel because it is standard practice in document design and looks entirely correct. A great many parsers discard the top and bottom margins before reading, on the reasonable assumption that they hold page numbers and running titles. If your email lives only there, your application arrives without an email address, and an application with no email address is frequently discarded outright.
Text inside a graphic
A designed header with your name in it, a logo containing your title, a skills wheel, a timeline drawn as an infographic. All invisible. This is also the mechanism behind the fully image-based resume, someone exports from a design tool with the text flattened, and the entire document parses to nothing.
A layout that works
PRIYA SHARMA priya.sharma@example.com | +44 7700 900123 | Leeds, UK linkedin.com/in/priyasharma SUMMARY Two or three lines. Full width. Plain sentences. EXPERIENCE Senior Analyst, Northwind Ltd, Leeds Mar 2021 – Jun 2024 • Led the migration of reporting onto a new warehouse • Built dashboards used weekly by forty people Analyst, Contoso plc, Manchester Sep 2018 – Feb 2021 • Owned the monthly revenue reconciliation EDUCATION BSc Economics, University of Leeds, 2015 – 2018 SKILLS SQL · Python · Tableau · financial modelling · forecasting
Plain, and it parses everywhere. The visual interest comes from typography and spacing, font weight, size and white space, none of which affects extraction. What you cannot have is structural layout doing the work.
Export settings that matter
From Word or Google Docs, use File → Save as PDF or Export, not Print → Save as PDF where a "print as image" option might be set. From design tools, check the export does not rasterise or outline the text, outlining converts letters into shapes, which look identical and extract as nothing.
Then run the one check that catches all of this: open the finished PDF and try to select a sentence. If words highlight, you have text. If a rectangle covers the block, you have a picture.
Check the result rather than trusting the list
Rules are a proxy. What matters is the text that actually comes out, and that is worth verifying rather than assuming, the ATS checker shows you exactly that, including which sections and dates were recognised. If your layout uses columns, start with the two-column guide, since nothing else matters until that is resolved.