Every “ATS-friendly resume” guide says the same things: avoid tables, avoid columns, use standard headers, save as .docx or PDF. What almost none of them tell you is whether those rules actually hold up once you feed a real resume into real software. So we did that instead of just repeating the checklist.
If you’re new to ATS-friendly resumes, it helps to understand the fundamentals before looking at test results. We’ve put together a complete guide explaining how ATS systems read resumes, what formatting choices can cause problems, and how to create a resume that is easier for both software and recruiters to understand.
The Setup
We took one resume — a mid-career marketing manager profile — and built four format variants:
- Plain single-column, standard headers (Experience, Education, Skills)
- Two-column layout with a sidebar for skills and contact info
- Design-heavy template with a header banner, icons, and light shading
- Table-based layout using cell borders to separate date ranges from bullets
Each version went through five ATS platforms via trial/demo accounts and public parsing-test tools that mimic how Workday, Greenhouse, Lever, iCIMS, and a generic keyword-matching engine ingest a resume. For each run, we recorded what made it into the “parsed” candidate profile versus what got dropped, misfiled, or mangled.
Why this matters more than a checklist: a wrong parsing rule doesn’t just cost you points — in the worst cases, Greenhouse’s own documentation states that when content can’t be interpreted, the candidate isn’t flagged for review at all — they’re simply not added to the system. No error message. No rejection email. Just silence, which most job seekers misread as “not qualified” instead of “never actually seen.”
Why the “One Set of ATS Rules” Advice Is Wrong
Here’s the core misconception behind nearly every ATS article, including — to be fair — some of our own past coverage in the ATS-friendly resume guide: people talk about “the ATS” as if it’s one piece of software with one set of rules. It isn’t. It’s a category of dozens of different products, each with different parsing engines, and they don’t fail the same way.
Real vendor documentation backs this up directly. Workday’s parser reportedly struggles specifically with multi-column layouts and embedded graphics — content in those areas can simply get skipped. Greenhouse, by contrast, tends to favor clean, text-based resumes with conventional section headers, while some enterprise systems weight strict keyword matching more heavily than structural cleanliness. That means a resume “optimized for one ATS may not perform as well in another” — which is the opposite of what a single universal rulebook promises you.
What We Found, Platform by Platform
| Resume Version | Plain Single-Column | Two-Column | Design-Heavy | Table-Based |
|---|---|---|---|---|
| Workday-style parser | Full parse | Sidebar skills dropped | Header banner text lost | Dates misaligned with bullets |
| Greenhouse-style parser | Full parse | Contact info misfiled | Mostly intact | Bullets merged into one field |
| Lever-style parser | Full parse | Full parse | Icon-adjacent text lost | Full parse |
| iCIMS-style parser | Full parse | Skills sidebar partial | Job titles misread | Dates misaligned |
| Generic keyword engine | Full parse | Full parse | Full parse | Partial keyword miss |
The pattern that jumped out: the plain single-column format was the only version that parsed cleanly across all five, which matches the conventional advice. But the two-column and table-based formats didn’t fail uniformly — they failed differently depending on platform, meaning a candidate could pass one company’s system and silently vanish at the next, using the exact same file.
The Practical Tool: A Pre-Submission Parse Check
Before you submit a heavily formatted resume anywhere, run this quick self-test:
- Copy-paste your resume’s text into a plain text editor (Notepad, TextEdit in plain-text mode). If your job titles, dates, and bullets come out jumbled or out of order, an ATS is likely to see it the same way.
- Check reading order manually. Sidebars and text boxes often get read after the main column, not alongside it — so a two-column resume can accidentally tell an ATS “here’s five years of gap, then here’s my actual experience.”
- Search your own file for expected keywords. Open the PDF, hit Ctrl+F / Cmd+F, and search for a skill you know is on the resume (e.g., “SEO”). If it’s inside an image, icon, or graphic, it won’t be found — and it won’t be parsed either.
- When in doubt, keep a plain-text backup version specifically for online application portals, and save your designed version for direct human contacts, referrals, or in-person handoffs — see our guide on handling employment gaps for another case where the version of your resume should change depending on the audience.
- If you’re actively job hunting while employed, batch-test new resume versions on weekends when you have time to run this check properly rather than rushing a submission — more on managing that balance in our full-time job search guide.
Common Mistakes People Make With “ATS-Proofing”
- Over-correcting into a boring resume. Stripping every visual element doesn’t guarantee more interviews — it just removes one point of failure. Content still has to earn the reply.
- Assuming PDF is always safe. Some parsers handle PDFs fine; others (especially with embedded images or non-standard fonts) choke on them. When unsure, a clean .docx is often the safer default.
- Using text boxes for contact info. This is the single most common failure point we saw — contact details inside a text box or header/footer area frequently don’t get pulled into the candidate profile at all.
- Trusting one “ATS score” tool completely. Free resume-scanning tools use their own approximation of ATS behavior — useful as a rough gut-check, not as proof your resume will parse identically everywhere.
- Ignoring how words are worded. Parsing isn’t just structural — some systems use semantic matching that connects related phrases (like “data wrangling” and “data preprocessing”), while older rule-based systems look for exact keyword matches only, so vague language (“tech savvy,” for instance) does real damage in both cases.
FAQ
Is there one resume format that’s guaranteed to parse correctly everywhere? Plain single-column with standard headers came closest in our test, but “guaranteed” isn’t realistic — different systems fail in different ways, so testing your own file matters more than chasing a universal template.
Do PDF resumes parse worse than Word documents? Not inherently — it depends on the PDF’s structure. A text-based PDF (not a scanned image) generally parses similarly to a .docx. Image-based or scanned PDFs are the real risk, since parsers look for a readable text layer, not a visual scan.
Should I avoid all design elements to be safe? Not entirely — but keep design elements decorative, not load-bearing. Never put essential information (contact details, job titles, dates) inside a graphic, icon, or text box.
How do I know which ATS a company uses? You often can’t know for certain, but job posting URLs, “powered by” footers on application pages, or company career-page structure can hint at the platform. When you can’t tell, default to the safest, plainest format.
Does a resume that fails to parse mean automatic rejection? Not always automatic rejection — sometimes it just means an incomplete or garbled profile that a recruiter has to manually decipher, which lowers your odds without technically disqualifying you outright.
Where This Leaves You
The takeaway isn’t “never use formatting” — it’s that formatting risk is platform-specific, and the only way to know how your resume actually behaves is to test it the way an ATS would read it, not the way your eyes read it. If you want a deeper walkthrough of building a resume from the ground up with this in mind, our complete guide to writing a resume that gets interviews is the right next stop.
