How to make your resume ATS-friendly
What actually breaks parsing (file formats, columns, tables, headers, fonts, dates), what is harmless, and a two-minute test that settles it for your own file.
What "ATS-friendly" really means
An ATS turns your file into a structured profile and lets recruiters search it. ATS-friendly therefore means exactly two things: the parser can read every fact on your page into the right field, and the words a recruiter would search for actually appear. Formatting is the first half; this guide is about getting it right without gutting your design.
File format: text is the only rule
A PDF whose text you can select and copy parses fine in every modern system. A DOCX parses fine everywhere, including the older systems. The only fatal format is a resume that is secretly a picture: a scan, a screenshot, or an export from a design tool that outlines its text. A parser gets nothing from it, and so does the two-second human skim.
If the posting asks for a specific format, send that format. The builder’s PDF export is a real-text render, and every signed-in account gets one free PDF download each month.
Thirty-second test: open your resume, select all, copy, paste into a plain text editor. If your details arrive complete and in order, a parser reads it too. The checker does the same thing with a real parser and shows the result field by field.
Columns, tables and text boxes
Parsers read a page in text order. A clean two-column PDF from a good tool usually survives (the columns come out one after the other), but tables, text boxes and multi-column layouts from design tools are where dates end up attached to the wrong job and headings dissolve. The failure is silent: the page looks perfect, the profile is scrambled.
The safe defaults: one column for the main story; if you want a sidebar, keep whole sections in it (skills, languages) rather than splitting one section across columns; never put facts in a table cell you would mind losing.
One specific trap deserves its own sentence: contact details in the page header or footer. Several parsers skip header and footer regions entirely, which deletes your phone number from the profile while it sits in plain sight on the page.
Headings: use the boring names
Parsers find sections by their headings. "Work experience", "Education", "Skills", "Summary" are recognised everywhere; "My journey", "Where I’ve made a dent" and untitled sections are how your work history ends up in the miscellaneous pile. Creativity belongs inside the bullets, not on the signposts.
Fonts, icons and skill bars
Any ordinary font parses: system fonts, Google fonts, serif or sans. The problems are decorative: letter-spaced headings can arrive as "E X P E R I E N C E", icon fonts turn your phone symbol into a random character, and a skill drawn as a bar or five dots reads as nothing at all. If a fact matters, it needs to exist as words: write "Advanced" next to the bar, write "Phone:" instead of relying on the icon.
Dates that machines can read
Screening filters sort by recency and compute lengths of employment, which only works on dates the parser understood. "Mar 2021 – Present" is the shape every parser reads. Keep one format for the whole document, give every role a start and an end (or Present), and put the range on its own line or right next to the title, not buried mid-sentence.
Photos and graphics
A photo does not break parsing; parsers skip images. Whether it belongs on your resume is a country question, not a technical one: expected in some markets, discarded in others. The country rules guide answers it per country. Charts and infographics are worse than photos: any fact that lives only inside a graphic is invisible to search.
Why the pretty templates fail
Most "creative" templates are built in design tools by designers optimising for the thumbnail. The features that make them look expensive (multi-column grids, tables for alignment, sidebars carrying half the content, headings as graphics, skill meters) are precisely the list above. The result photographs well and parses badly, which is the worst trade available: recruiters spend seconds on the look and searches run on the parse.
It is a solvable problem: a template can be designed to look sharp and emit clean text. Ours are tested for exactly that: every one ships with a documented extraction test you can check.
The checklist
- Real, selectable text, never a scan or an image export.
- PDF or DOCX; match what the posting asks for.
- One column for the main story; whole sections only in any sidebar.
- Standard headings: Work experience, Education, Skills, Summary.
- Contact details in the body of the page, as text, never only in a header, footer or icon.
- Dates as "Mar 2021 – Present", one format throughout.
- Every fact that matters exists as words, not only as a bar, chart or graphic.
- Paste-into-notepad test passes, or run the free checker.
Common questions
Is PDF or Word better for an ATS?
Both parse reliably in modern systems as long as the PDF contains real text. Send what the posting asks for; when nothing is specified, a text-based PDF keeps your layout everywhere.
Are two-column resumes ATS-safe?
Often, but not always: columns are read one after the other, so keep whole sections per column and never split one section across two. When in doubt, run the file through the checker and look at the extracted order.
Will a photo get my resume rejected by the ATS?
Not by the software; parsers skip images. Whether a human expects or discards photos depends on the country you are applying in.
Do I need to strip all design and send a plain document?
No. Clean design and clean parsing coexist fine; the rules are about structure (columns, tables, images-as-text), not about looking plain.