Debunking ATS myths: what really breaks resume parsing

By the Reach team · Updated August 01, 2026

Most ATS software doesn't reject you. It parses your resume into fields (name, title, dates, skills) and hands the result to a recruiter, who does the rejecting. The software's job is closer to data entry than gatekeeping, and knowing that changes what's actually worth fixing in your formatting.

The 75 percent myth

You've probably seen the claim that 75 percent (or 70, or 90, depending on who's selling the fix) of resumes get auto-rejected by ATS before a human ever sees them. We can't find a credible source for any of these numbers, and neither can the people who cite them, since the citation is usually another article citing the same unverified figure. Treat it as marketing, not research.

What's true is narrower and less dramatic: applicant tracking systems (Workday, Greenhouse, Lever, iCIMS, and a long tail of others) parse your resume into structured fields, and if the parsing goes badly, a recruiter sees a mangled version of your work history. That's a real problem. It is not the same as a robot silently deleting your application because you used a two-column layout.

Some systems do support rules-based filtering, where a recruiter sets up automatic knockouts for things like "must have," minimum years of experience, or work authorization. If you fail one of those, you can be filtered out. But that's a recruiter's configuration choice, not a universal ATS behavior, and it has nothing to do with formatting.

What an ATS actually does

Under the hood, most systems run your resume through a parsing engine that tries to extract structured data: contact info, job titles, company names, dates, degrees, and a block of "skills" or keywords. That structured data populates a candidate profile the recruiter searches and filters. Your original file (PDF or Word doc) is usually also stored and viewable, so even a parsing error doesn't necessarily erase your actual resume from the recruiter's view. It just means the searchable fields might be wrong or empty, which can hurt you when a recruiter filters candidates by keyword or years of experience.

So the real risk isn't rejection by algorithm. It's your dates parsing wrong, your most recent title ending up in the wrong field, or your skills section not registering at all because it was formatted in a way the parser didn't expect.

What parsers really extract

Parsing engines vary, but most are built around the same targets:

• Contact information, usually pulled from the top of the document with pattern matching for emails, phone numbers, and sometimes LinkedIn URLs.
• Work history, as a sequence of job title, company, and date range, inferred from formatting patterns (bold text, consistent line structure, recognizable date formats).
• Education, matched against known degree and institution patterns.
• Skills or keywords, either from a dedicated skills section or scraped from the whole document.

All of this depends on the text being extractable in a sensible reading order and the structure being predictable enough for the parser's pattern matching to work. That's the whole ballgame. Nothing about parsing cares whether your resume looks pretty.

What actually breaks parsing

A short list, because the real list is short:

• Text inside images. If your resume is a photo, a scanned PDF, or a graphic with text baked in, there is no text to extract. This is the single most reliable way to have your resume parsed as blank.
• Text boxes and tables used for layout. Some parsers read a page left to right, top to bottom, ignoring the boxes entirely, which scrambles the order text comes out in. A two-column layout built with text boxes can interleave your job titles with your skills list in a way that reads as nonsense once parsed.
• Headers and footers. Some systems skip these sections outright. If your contact info lives only in a header, it may never make it into the parsed record.
• Unusual file types. Stick to PDF or .docx. Some systems still struggle with .pages files, image-based PDFs, or oddly encoded exports from design tools.
• Non-standard section headers. "Where I've Made an Impact" instead of "Experience" might read as charming to a person and as nothing to a parser looking for a small set of expected header strings.
• Special characters and symbols used as bullets or dividers. Most parsers handle standard bullets fine, but hand-drawn icons, emoji, or decorative dividers pulled from a font's symbol set can turn into garbage characters or get dropped.

Notice what's not on this list: font choice, a second column that's built with an actual table your reader software supports, color, a subtle background shade, or a resume that's one page instead of two. None of that affects whether the text is extractable.

What's merely ugly, not broken

This is where a lot of formatting advice goes wrong: it treats "might look unpolished" and "will fail to parse" as the same category of risk. They aren't.

The safest general rule: if you're not sure whether a design choice is purely visual or structurally load-bearing, ask whether the same information would still be there if you selected all the text and pasted it into a plain text file. If it would come out garbled or out of order, a parser will likely have the same problem.

Keyword stuffing doesn't work the way people think

The advice to load your resume with keywords from the job posting isn't entirely wrong, it's just usually applied badly. Skills fields do get searched, and matching the language a recruiter or hiring manager actually used in the posting (rather than a synonym) can matter when someone runs a keyword search across a candidate pool. That part is real.

What doesn't work is repeating a keyword five times in white text, cramming a skills section with every tool you've ever touched once, or restating the job title verbatim in a way that reads as obviously gamed to the human who eventually opens the file. Recruiters read the resumes that make it to their queue, and a resume that's clearly been keyword-stuffed for a machine reads as keyword-stuffed to a person too. Most systems also don't rank or score you higher purely for keyword density, since that's not typically how the search and filter functions are built.

The better version of this advice: use the actual terms from the posting where they honestly describe your experience (say "project management" if the posting says that and it's true of your work, rather than only writing "led cross-functional initiatives"), and put your skills and tools in a dedicated, clearly labeled section so they're easy for both a parser and a human to find.

A format that works

None of this requires cleverness. A resume that parses reliably and reads well for a human tends to look like this: a single column, standard section headers (Experience, Education, Skills), contact info in the body of the document rather than only in a header, consistent date formatting, real bullet characters rather than symbol-font glyphs, and a plain PDF or .docx export rather than an image or an unusual file type. If you use a template, open the exported file and check that it reads in a sane order when you select and copy all the text.

If you're applying to a lot of roles and want the formatting checked and the keyword matching handled without doing the last mile by hand every time, that's the kind of repetitive work a tool like Reach is built for. But the formatting rules above are worth knowing regardless of what you use to apply, because most of what determines whether your resume parses cleanly is just plain, unglamorous consistency.