Your resume can be perfectly written and still never reach a human
Somewhere in our guide to writing a resume with AI, we said this: fix the file format first, because no amount of prompting repairs a parsing problem. That line deserved more than a sentence. A resume can nail every metric, every achievement, every line of positioning, and still get rejected before a hiring manager ever opens it, because the applicant tracking system that scans it first couldn’t read half the page.
This isn’t about writing quality. It’s about whether the software standing between you and a human being can actually extract the words on your resume in the right order. Here’s what genuinely breaks that, what’s an outdated myth you can ignore, and how to check your own resume before you submit it anywhere.
What an ATS is actually doing
An applicant tracking system isn’t judging your resume the way a person would. It’s parsing the document into plain text, pulling out fields it recognizes (name, dates, job titles, skills), and matching that text against the keywords a recruiter searched for. It reads in a fairly rigid, linear order, roughly left to right, top to bottom, the way you’d read a page if someone covered up everything except one line at a time.
Platforms like Greenhouse, iCIMS, and Workday handle a large share of today’s job applications, and while each system parses slightly differently under the hood, they all share the same basic weakness: none of them read a page the way a human eye does. That single fact explains almost every formatting mistake on this list. Anything that breaks the linear reading order, or that isn’t actually text at all, has a real chance of getting scrambled or dropped entirely.
- Life Is Noteworthy. Create a resume that is noteworthy and will stand out from the crowd with this Southworth Resume Paper!Make a good…
- Resume paper is ideal for resumes, cover letters, and thank-you notes
Last updated on 2026-09-02
What actually breaks parsing
Multi-column layouts.
A two-column resume with your experience on the left and skills on the right looks clean to a human eye. To a parser reading left to right, it can read straight across both columns, stitching a line from your job history to a line from your skills list as if they were one sentence. Some modern systems handle columns better than they used to, but “some” isn’t good enough odds when the fix is free: use a single column.
Tables.
Table cells sometimes get skipped entirely, sometimes get read in the wrong order, and sometimes get pulled out and dumped at the end of the document with no context. If you’re using a table to organize your skills or your work history, you’re gambling on how well this particular ATS handles table cells. Use plain text with line breaks instead.
Text boxes and image-based headers.
A stylish header with your name in a graphic banner, or a sidebar built as a text box rather than the document’s actual body text, often gets skipped completely because it isn’t part of the main text flow the parser reads. If your name and contact info live in a text box, there’s a real chance the system never sees them.
Contact info in a header or footer.
Plenty of resume templates put your name, phone, and email in the document header so they repeat on every page. Plenty of parsers skip header and footer regions by default, because that’s typically where letterhead and page numbers live, not candidate data. Put your contact info in the main body of page one instead.
Icons standing in for words.
A little phone icon next to your number, an envelope icon next to your email, a location pin next to your city: these read as decoration to a parser, not as the word “Phone” or “Email.” If the icon is the only label, the field might parse as blank. Use the actual word, or at minimum, don’t rely on the icon alone.
Unusual section headers.
“My Journey” instead of “Experience.” “What I Bring” instead of “Skills.” Creative headers might read well to a human, but a parser mapping your resume to a database field is looking for recognizable terms: Experience, Education, Skills, Summary. Stick to the standard ones.
Scanned or image-based PDFs.
If your PDF is actually a photo or scan of a printed page rather than a text-based export, there’s no text underneath for the parser to extract at all. This is different from a normal PDF export, which almost every ATS today can read just fine, more on that below.
A few smaller things worth fixing while you’re at it.
Decorative bullet glyphs (arrows, stars, or custom symbols instead of a plain round or square bullet) occasionally render as a stray character or blank space rather than a bullet at all. Inconsistent date formats across your work history, “Jan 2021” in one job and “01/2021” in the next, can confuse systems that calculate your total years of experience from parsed dates. Neither of these causes an outright rejection on its own, but both are free to fix once you know to look for them.
Quick reference: safe vs. risky by element
| Resume element | ATS-safe | Risky |
|---|---|---|
| Page layout | Single column | Multi-column or side-by-side sections |
| Skills, work history | Plain text with line breaks | Tables |
| Name and contact info | Main body of page one | Header, footer, or text box |
| Section titles | Experience, Education, Skills | “My Journey,” “What I Bring” |
| Icons | Word plus icon, or word alone | Icon-only labels |
| File type | Text-based PDF or .docx | Scanned image PDF |
| Bullets | Plain round or square bullets | Decorative symbols or custom glyphs |
| Dates | Consistent format throughout (e.g., “Jan 2021”) | Mixed formats across entries |
The self-test that takes two minutes
Before you submit anything, copy the entire text of your resume and paste it into a completely plain text editor: Notepad, TextEdit in plain-text mode, or a blank email draft with formatting stripped. Look at what survives the trip.
If your contact info is missing, it was probably in a header or text box. If two unrelated lines have merged into gibberish, you likely have a column or table problem. If a whole section vanished, check whether it was built as an image or a text box rather than real text. This won’t perfectly replicate what every ATS does, but it catches the majority of real formatting failures in about the time it takes to make coffee.
AI Resume Prompts: How to Write a Resume That Actually Sounds Like You
What’s actually a myth at this point
“PDFs always fail ATS scans.” This was true years ago with older systems, and it still shows up constantly in career advice. Modern ATS platforms, the ones most mid-size and large companies actually use now, parse text-based PDFs just fine. The real risk isn’t the PDF format itself, it’s a PDF that’s secretly a scanned image, or one exported from a design tool that flattens text into paths instead of readable characters. If you’re not sure which you have, run the copy-paste test above.
“You need a .doc file, not .docx.” This one’s been outdated for a long time. Current systems handle .docx without issue. If a specific job posting explicitly requests .doc, follow that instruction, but there’s no reason to default to it otherwise.
“One page is a hard formatting rule.” This is a content and readability question, not a parsing one. A two-page resume with clean, single-column formatting parses exactly as well as a one-page version. Length affects whether a human keeps reading, not whether the software can read it.
“White text keyword stuffing beats the system.” Hiding invisible keywords in white text to trick an ATS into a higher match score is a trick some job seekers still try. Modern systems increasingly flag or ignore this, and worse, if the trick fails and a human opens the document, invisible keyword lists visible on copy-paste look exactly like what they are. It costs more than it gains.
Myth vs. reality, at a glance
| Myth | Reality |
|---|---|
| PDFs always fail ATS scans | Text-based PDFs parse fine on modern systems; scanned image PDFs are the actual risk |
| You need a .doc file, not .docx | .docx is handled without issue by current systems |
| One page is a hard formatting rule | Length affects human readability, not ATS parsing |
| White text keyword stuffing beats the system | Increasingly flagged or ignored, and risky if a human opens the file |
The quick checklist before you submit
Run through this once, right before you hit submit on any application:
- Single column throughout, no side-by-side sections
- No tables for skills, experience, or any other content
- Contact info in the main body of page one, not a header or footer
- No text boxes; everything is part of the document’s actual text
- Standard section headers: Experience, Education, Skills, Summary
- No icon-only labels; the actual words are present
- File is a genuine text-based export, not a scanned image
- Copy-pasted into a plain text editor and everything survived intact
Frequently Asked Questions
Does font choice matter for ATS parsing?
Mostly no, as long as it’s a standard, widely available font like Arial, Calibri, or Georgia. Decorative or highly stylized fonts can occasionally cause character recognition issues, but this is a much smaller risk than columns, tables, or text boxes.
Should I submit a PDF or a Word document?
A text-based PDF is safe for the large majority of modern systems. If a job posting specifies a format, follow that instruction over any general rule. When in doubt and no format is specified, either works, the bigger risk is layout, not file type.
Do headers and footers really get skipped by ATS software?
Often, yes. Many systems are built to ignore repeating header and footer content because that’s traditionally where non-candidate information lives. Keep contact info in the main body to be safe.
How do I know if my resume actually passed an ATS scan?
There’s no universal way to know for certain from the outside, since every company’s system is different. The self-test in this guide won’t guarantee a pass, but it catches the formatting mistakes that cause outright rejection, which is the biggest and most fixable risk.
Does my cover letter need to follow these same rules?
Less strictly. Most systems parse cover letters more loosely than resumes, or don’t parse them for keyword matching at all, since the resume is usually the primary screening document. Still worth avoiding tables and text boxes there too, but the stakes are lower than they are here.
