What ATS Software Actually Reads From Your Resume

Search “beat the ATS” and you’ll find the same claim repeated on hundreds of sites: 75% of resumes are rejected by an ATS before a human ever sees them. Nobody citing it links to a study, because there isn’t one — the number traces back to a 2012 marketing pitch from a company called Preptel, which went out of business the following year and never published a methodology, sample size, or source. It’s been copy-pasted through career blogs for over a decade with the citation stripped off each time. Below is what’s actually documented — by the vendors themselves — about what these systems do with your resume file.

What an ATS is actually for

An applicant tracking system is a database with search and filtering built in, not a rejection machine. Greenhouse’s own documentation describes resume parsing as scanning an uploaded file and auto-filling candidate fields — name, email, phone, current title, education — so a recruiter doesn’t have to type it in by hand. When parsing fails, Greenhouse’s help center says the fields are simply left blank for the recruiter to fill in manually. Lever’s help center describes the same thing: parsed data populates the candidate’s profile, and if a field can’t be extracted, you enter it yourself. Neither vendor documents the parser rejecting an application because it couldn’t read the file — a failed parse means more manual work for the recruiter, not an auto-decline for you.

That matches what recruiters who work inside these systems report: most resumes that reach a requisition get looked at by a person, because sorting is the whole point of the database — a recruiter searches and filters a pool of hundreds, they don’t let software silently discard most of it before opening the tool.

The one real auto-rejection mechanism — and it’s not the resume file

There is a genuine automatic-disqualification feature in some hiring platforms, and it’s worth describing accurately because it’s often confused with resume parsing. Workable’s help center documents an “auto-disqualify” setting for application forms: you can mark specific Yes/No screening questions — “Are you authorized to work in this country without sponsorship?”, “Do you have X years of experience?” — so that a “No” answer automatically routes the application to a disqualified list. This is answer-based, applied to the application questions the candidate fills out on the form, not something the system infers by reading the resume document.

That’s the important distinction. Nothing in Greenhouse, Lever, or Taleo’s own documentation describes the resume text being scored and auto-rejected. The screening logic that does exist lives in structured yes/no questions the candidate answers directly — which means if you’re ever auto-rejected in one of these systems, it’s much more likely because of how you answered a screening question than because of a font choice on your PDF.

What genuinely breaks parsing

None of this means formatting is irrelevant — it just breaks the wrong thing. A badly formatted resume doesn’t get “rejected”; it gets parsed badly, which means the fields a recruiter searches by (title, dates, skills) come out empty, scrambled, or wrong. That’s a real cost even without an auto-reject step. Here’s what the vendors themselves flag as actual failure modes:

Text inside images, or a scanned PDF. Oracle’s Taleo Business Edition documentation states plainly, in its 24A release notes, that a resume in image format will not be parsed at all. There’s no text layer to extract — a scanner or “export as image” just produces a picture of text, and nothing downstream can read it without OCR first.
Multi-column layouts. Resume-parsing vendor Textkernel, whose engine sits behind a number of ATS products, estimates that at least 15% of resumes use a column layout and calls it a genuinely hard computer-vision problem — a parser reading left-to-right can interleave your job titles from one column with the bullet points from another.
Text boxes, headers, and footers. Multiple parsers skip content placed in Word text boxes or in header/footer layers entirely. If your name and contact info are the only thing in a header, that’s the one section most likely to go missing.
Tables used for layout. Using a table to force a resume into a grid (rather than to actually present tabular data) confuses the same column-reading logic as multi-column layouts.
Non-standard section headings. “What I Bring to the Table” instead of “Experience” doesn’t map to any field a parser is trained to recognize — it just gets dumped into miscellaneous text instead of populating the work-history field.
Corrupted or unusual PDF generation. Some design tools and older Word-to-PDF paths produce a PDF whose visual layout looks fine but whose underlying text order, ligatures, or glyph mapping is broken — “fi” or “ffi” pairs turning into garbage characters is a known symptom.
Oversized files. Greenhouse’s documentation calls out a hard 2.5 MB file size limit, usually blown past by embedding a high-resolution headshot or background graphic.

What’s fine — despite the folklore

A lot of the advice floating around demonizes things that the primary sources don’t actually flag as a problem:

PDF as a format. A text-based PDF exported from Word or Google Docs is a good submission — it preserves your layout for the human reader while still parsing cleanly, because the text layer is intact. The failure mode isn’t “PDF”; it’s an image-only PDF, which is a different thing (see above).
A single column with clear headings. This is the format every parser handles best, not a compromise.
A reasonable two-column layout, if it’s built with your word processor’s actual column feature rather than manually positioned text boxes. Not every parser handles it equally well, but it’s not the automatic disqualifier some guides claim.
Standard section names — Experience, Education, Skills, Summary. Boring is the goal here, not a weakness.
Normal bullet points. Bullet characters themselves parse fine; it’s tables and text boxes that cause trouble, not punctuation.

Myth vs. what’s actually documented

Claim	What’s actually true
”75% of resumes are auto-rejected by ATS”	Unsourced 2012 marketing claim from a defunct company. No vendor documents this behavior.
”PDFs don’t parse, use .docx”	A text-based PDF parses fine. An image-only PDF (scanned or exported as a picture) doesn’t — that’s the real distinction.
”The ATS scores your resume and rejects low scorers automatically”	The one documented auto-disqualify mechanism (Workable) triggers on your answers to screening questions, not on resume text.
”Any two-column layout gets your resume thrown out”	Columns make parsing harder, not impossible — Textkernel flags them as an accuracy problem, not a hard failure, and simple column formatting fares better than text boxes.
”Creative headings help you stand out to the algorithm”	Non-standard headings (“What I Bring”) don’t map to any recognized field — use Experience, Education, Skills.
”A scanned resume is fine as long as it looks readable”	Taleo’s own docs state image-format resumes simply don’t get parsed — there’s no text to extract without OCR.

The 30-second test anyone can run

You don’t need special software to check your own resume. Open your exported PDF, select all the text (Cmd/Ctrl+A), copy it, and paste it into a plain text editor — Notepad, TextEdit, or a blank browser address bar works. Look at what comes out:

Is the text in the right order — your most recent job first, bullets grouped under the right heading?
Is anything missing — your name, a whole section, your contact info?
Are words scrambled together, or interleaved from two columns?

If it reads cleanly top to bottom, a parser will read it the same way. If it’s a jumbled mess in a plain text box, that’s exactly what a parser sees too — no formatting to fall back on, no visual layout to help it guess. On macOS or Linux, the same check from a terminal is pdftotext resume.pdf -, which dumps the extracted text layer directly. If that command returns nothing, your PDF has no text layer at all — it’s effectively an image, and a parser needs OCR to get anything out of it. Lunchbox Hands’ Image to Text tool runs that same OCR step in your browser, which is a decent way to see, concretely, how much information a scanned resume loses on the way in — line breaks, spacing, and section structure often don’t survive the round trip.

A machine-readable checklist

The goal here isn’t “beating” a system — it’s producing a document a parser can read cleanly, the same way you’d want any reader to follow it without tripping. That’s:

Export as a real PDF with a selectable text layer — never a picture or scan.
Use a single column, or a genuine two-column layout built with your editor’s column tool, not manually placed text boxes.
Put your name and contact details in the body of the document, not in a header or footer.
Use standard section headings — Experience, Education, Skills.
Avoid tables for layout — reserve them for genuinely tabular data, if you use them at all.
Keep dates in a consistent, conventional format (e.g. “Jan 2023 – Present”).
Stick to a standard font your export pipeline renders faithfully; run the copy-paste test afterward to catch ligature or glyph issues.
Keep the file under a couple MB — drop the embedded headshot or background graphic if you have one.

Building one that starts clean

The easiest way to satisfy all of the above is to start from a template built to those constraints rather than retrofitting a design-first resume afterward. The Resume Builder ships a single-column ATS-friendly template plus a compact two-column option, and every export is real selectable text — never a rendered image — so the copy-paste test above passes by construction. It’s free, runs with no account, and there’s no paywall hiding behind the download button. If you already have your resume as structured data, it also imports and exports JSON Resume, so you’re not retyping everything.

If you’re assembling a resume from Markdown or plain text instead, Markdown to PDF and Text to PDF both produce the same kind of clean, real-text PDF — useful if you want full control over the source file rather than working inside a template.