How ATS Systems Actually Read Your Resume

The resume that should have worked

You know the feeling. You read the posting twice, you were genuinely qualified — maybe even a little overqualified — and you spent an hour getting the resume just right. Nice two-column layout, a little skills sidebar with a shaded background, your name in a tasteful serif font at 22pt. You hit submit. And then... nothing. No rejection email, no interview request, just silence that stretches into "guess that one's dead."

Here's the thing almost nobody tells you: that resume probably never got rejected by a person. It got mangled by software before a human ever laid eyes on it. Not because you weren't qualified — because the file you submitted didn't survive contact with the parser.

Let's actually open the hood on what happens between "Submit Application" and a recruiter's inbox, because once you see it, you'll never format a resume the same way again.

What actually happens in the 60 seconds after you hit submit

When your resume lands in an Applicant Tracking System — Greenhouse, Lever, Workday, iCIMS, Taleo, SmartRecruiters, whatever the company happens to run — it does not get "read" the way you're picturing. It gets ingested.

The pipeline looks roughly like this:

1. File type detection. The system checks whether you sent a PDF, a DOCX, or (please don't) a .pages or image file.
2. Text extraction. The parser pulls a raw stream of characters out of the document. This is the step that trips people up, and we'll get into why in a second.
3. Tokenization and field segmentation. The extracted text gets chopped into tokens and run through a model (often a mix of regex heuristics and a trained classifier) that tries to answer: is this line a name? A job title? A date range? A bullet under "Experience"? A skill?
4. Structured record creation. The system builds a candidate record — name, email, phone, a list of job objects (company, title, start date, end date, description), an education list, a skills array — and stores your full resume text as a searchable blob alongside it.
5. Scoring and ranking. Depending on the platform, your structured record gets compared against the job requisition — keyword overlap, title match, years of experience — and you're slotted into a ranked or filtered list.

All of that happens automatically, in seconds, before any recruiter opens your file. The PDF you so carefully designed is, at this stage, just raw material for a data-extraction pass. And extraction pipelines are unforgiving about exactly the kind of visual polish that makes a resume look good to a human.

The parsing step, in more detail

Here's the part that matters most: a parser doesn't see your layout. It sees a sequence of characters in whatever order the file's internal structure hands them over.

For a Word doc, that's relatively predictable — DOCX is just XML under the hood, and the text nodes are ordered the way you'd expect. For a PDF, it's messier. A PDF doesn't actually store "paragraphs" — it stores instructions for where to draw each character on the page. A well-behaved single-column PDF draws text top-to-bottom, left-to-right, so extraction is clean. A two-column PDF, or one with a sidebar, often gets drawn column-by-column or in whatever order the design software happened to lay it out — and when the parser extracts "in document order," it can read straight across both columns, splicing your Skills sidebar into the middle of your most recent job description. There's no need for a fancy name for what happens next: the parser just gets the reading order wrong, and your bullet about leading a six-person team can end up mid-sentence with "Python, SQL, Tableau" from the sidebar.

Tables have the same problem, for the same reason — a parser reading "left to right, top to bottom" doesn't know to finish Cell A before moving to Cell B, so it frequently reads across a row instead of down a column, shredding whatever structure the table was supposed to convey.

Text boxes are worse, not scrambled but often invisible — because a text box is a floating object outside the main text flow, some parsers skip it entirely. If your phone number lives in a text box in the header (common in a lot of "designer" templates), it may simply not exist as far as the ATS is concerned. Same story with icons: that little phone glyph next to your number, or the envelope icon before your email, frequently gets extracted as a garbage character or dropped outright — occasionally taking the whole line with it.

Fonts matter less than layout, but they're not nothing. Stick to standard, embeddable fonts (Calibri, Arial, Georgia, Times New Roman) at a normal body size — 10 to 12pt. Ultra-small text sometimes gets treated as noise and discarded; novelty or script fonts can render as garbled Unicode once extracted as plain text, even though they look fine to your eye in the PDF viewer.

And section headers matter more than people expect. Parsers lean heavily on a small, fairly rigid dictionary of expected headers — "Experience" or "Work Experience," "Education," "Skills," "Summary." If you get clever and title a section "My Journey" or "What I Bring," the classifier that's trying to figure out what kind of content follows may misfile the whole block — sometimes lumping it in with an objective statement, sometimes just failing to associate any of those bullets with your work history at all. The keywords are physically present in the document. They just don't get attached to the field a recruiter searches against.

On the PDF-vs-DOCX question specifically: this rotates every year but the 2026 shape is — a clean, single-column, text-based PDF (not a flattened image, not something exported from a design tool like Canva or Illustrator) now parses about as reliably as DOCX on most modern platforms, Greenhouse included. Where the gap reopens is exactly where you'd guess: multi-column or heavily designed layouts still lose meaningfully more fidelity as a PDF than the same content would as DOCX, because DOCX's XML structure enforces a text order that PDF doesn't. If your resume is single-column with standard headers, format is mostly a non-issue. If it's not, DOCX is the safer bet on parser-heavy platforms like Workday, Taleo, or iCIMS.

What recruiters actually see on their end

This is the part that reframes everything: the recruiter isn't reading your resume as a document. They're reading (and searching, and filtering) your resume as a database record.

Once the parse completes, most ATS platforms populate a candidate card or profile: your name and contact block up top, a structured work-history list (with company/title/dates as filterable fields), an education entry, and a skills array. Some platforms, Greenhouse among them, now generate a short AI summary of the candidate so the recruiter doesn't have to open the raw file cold. The recruiter can usually still click through to view your actual PDF — but the first impression, and the thing they're searching and sorting against, is the structured version your resume got turned into.

This is why a resume that "looks amazing" but parses badly can genuinely lose to a plainer one that parsed cleanly. If the parser attached your job title to the wrong company, or dropped your most recent role's bullets into an unlabeled blob, you don't show up when a recruiter searches "led a team of" or filters for your actual seniority level — even though a human skimming the PDF would have gotten it immediately.

Then there's keyword matching, which is where a lot of good-faith effort gets wasted. Not every platform is created equal here: some do genuine stemming (matching "managed" to "management" to "manage"), a few attempt semantic matching (loosely connecting "revenue growth" to "sales performance"), but plenty still do straightforward literal or lightly-stemmed string matching. Casing is usually normalized — "Product Manager" and "product manager" score the same almost everywhere — but exact terminology often isn't interchangeable under the hood. If the posting says "TypeScript," a resume that only says "JavaScript" doesn't automatically get credit. If it says "CI/CD," writing "continuous integration and deployment" is a coin flip depending on the platform. The safest posture is: assume the least generous parser, and mirror the posting's exact nouns.

Practical takeaways — before and after

A few concrete swaps that map straight onto everything above:

Contact info. Before: a phone icon and envelope icon in a styled header text box. After: plain text on one line — Jane Doe · (555) 123-4567 · jane@email.com · Austin, TX — sitting in the main body, not a floating element.

Layout. Before: two-column resume with a shaded skills sidebar running the length of the page. After: single column, top to bottom — Summary, Experience, Skills, Education — each its own clearly labeled section.

Section headers. Before: "My Journey" or "What I Bring to the Table." After: "Experience" and "Skills," plain and boring on purpose — boring is exactly what parses cleanly.

Terminology. Before: "Familiar with modern JavaScript frameworks." After: "Built and shipped features in React and TypeScript" — if that's what the posting asked for and it's true of your background, use their exact words.

Skills block. Before: a graphic with shaded bars showing "proficiency levels." After: a plain grouped list — Languages: Python, SQL, TypeScript — that both a parser and a human can read in half a second.

None of this is about dumbing down your resume. It's about making sure the sharp, specific things you actually did survive the trip from PDF to database record intact.

Where Penny Resume fits in

We built Penny Resume because we kept running into this exact problem, over and over, for ourselves and for friends we were helping job-hunt. Somebody would have a genuinely strong background and a resume that photographed beautifully, and it would just vanish into ATS silence — not because the person wasn't qualified, but because the layout that looked great in a PDF viewer had scrambled itself the moment a parser got hold of it.

The way it works: you keep one master profile — your real experience, written once, honestly. Every time you find a posting worth applying to, you paste it in and Penny Resume generates a fresh, tailored PDF for that specific role: single-column, standard section headers, the posting's own keywords worked into your summary and bullets verbatim, nothing floating in a text box that a parser might drop. It's genuinely what we use for our own job searches, which is a big part of why it's built the way it is — parser-first, then pretty, not the other way around.

If you've got a posting sitting open in another tab right now that you've been putting off because formatting a resume for it feels like a chore, that's exactly the moment to try it. Paste it in and see what comes out — I'd genuinely like to know what you think.