ATS Resume Format
An ATS-safe resume is an unremarkable one: single column, standard headings, real text, contact details in the body. That is close to the entire specification, and everything else usually attributed to ATS compatibility is either optional or invented.
The reason to get it right is not that a parser judges you. It is that a failed parse produces a candidate record missing your phone number or with your skills merged into your job titles, and neither is recoverable from your side.
The rules that matter
Nothing on that list requires a special template or a paid tool. A plain document written in an ordinary word processor satisfies all seven by default, which is why the market for ATS-optimised templates is larger than the problem.
| Rule | Why |
|---|---|
| Single column | Two columns can be read across, interleaving unrelated text |
| Contact details in the body | Header and footer regions are ignored by some parsers |
| Standard headings | Experience, Education, Skills — not "Where I Have Been" |
| Real text, not images | An image-based PDF extracts to nothing |
| No tables for structure | Cell order does not always survive extraction |
| Conventional date format | Consistent MM/YYYY or Month YYYY throughout |
| Common font | Substitution reflows a page you carefully fitted |
The two-minute test
Open your PDF and try to select a line of text with the cursor. If nothing highlights, the file is an image and will parse to nothing — re-export it from the source document rather than from a design tool.
Then select the whole document, copy it, and paste into a plain text editor. What appears is approximately what a parser sees. Read it: are the job titles adjacent to their employers and dates? Are your skills in one block rather than scattered between roles? Is your phone number present at all?
Whatever is wrong in that plain-text version is wrong in the parsed record. It is the single most useful five minutes available on a resume and almost nobody does it.
Headings, and the ones that break things
Parsers recognise section headings from a known vocabulary. "Work Experience", "Professional Experience" and "Experience" are all recognised; "My Journey" and "Where I Have Made an Impact" are not, and content under an unrecognised heading may land nowhere.
The same applies to sub-structure. Employer, title, location and dates on the same line or in a predictable order parse cleanly; a creative arrangement where the date floats in a separate visual column does not.
This is the cheapest possible win. Conventional headings cost nothing, remove an entire class of failure, and no reader has ever preferred a resume for having invented its own section names.
What genuinely does not matter
A large share of ATS advice concerns these. Following it is not harmful, but the effort produces nothing, and it displaces the checks in the section above that actually change outcomes.
- Page count — parsers read content, not pages.
- PDF versus Word, provided the PDF is text-based.
- Colour, used moderately, since it does not affect extraction.
- Bullet character, as long as it is a real bullet rather than an image.
- Font size, within readable limits.
- Whether you used a template or wrote it yourself.
Where the job title should appear
Recruiters search the database by title far more than by anything else, so having the posting's exact title in your document is the highest-value single word choice on the page — provided it honestly describes you.
Where your internal title differs from the industry one, the honest construction is both: "Operations Analyst (internal title: Business Systems Specialist II)". That parses, searches and misrepresents nothing.
What does not work is claiming a title you did not hold. It surfaces at reference check, where employers confirm title as a matter of routine even when they will say nothing else.
Templates, and what to avoid buying
The templates that cause parsing failures are almost always the visually designed ones — sidebars, icon rows, skill rating bars, headshots and two-column grids. They look better on screen and they are the origin of most garbled candidate records.
Skill rating bars deserve a specific mention: they convey nothing to a parser, they are unverifiable to a human, and they invite the question of what four bars out of five actually means. Name the skill and let the experience section evidence the level.
A word processor's built-in plain resume template is fine. So is a document you formatted yourself with headings and bullets. Neither needs to be bought, and neither is what fails.
If you are already using a designed template and it has been working, there is no reason to abandon it — run the plain-text test above and keep it if the output is clean. The rule is about outcomes rather than aesthetics, and plenty of attractive documents parse perfectly well.
Frequently asked questions
Single column, standard section headings, real selectable text, contact details in the body rather than a header, no tables used for structure, and consistent dates. A plain document from an ordinary word processor satisfies all of that by default.
Try selecting text in the PDF — if nothing highlights it is an image and will parse to nothing. Then copy the whole document into a plain text editor: what you see is roughly what the parser sees.
No. The templates that cause parsing failures are the designed ones with sidebars, icons and rating bars. A plain built-in template or a document you formatted yourself already satisfies every rule that matters.
Yes, where it honestly describes you — recruiters search by title more than anything else. Where your internal title differs, list both rather than replacing one with the other.