How to Read Your Resume the Way an ATS Parser Does

Why "will I pass" is the wrong question

Type "how does ATS read my resume" into a search bar and most of what comes back treats the software like a judge: it scores you, it rejects you, it decides. That framing isn't quite right, and it isn't even the useful part of the question. Under the hood, most applicant tracking systems are running a parser — a piece of software that extracts fields (name, phone number, job titles, dates, skills) out of your file and drops them into a database a recruiter later searches and filters. Nothing about that step is a verdict. It's closer to a very literal-minded transcription.

What can go wrong isn't a low score. It's a bad transcription: your phone number lands in the wrong field, a job title splits mid-sentence, a whole section goes missing because the parser couldn't find where it started. The recruiter never sees a rejection notice caused by this — they just see an incomplete or garbled profile, if they see the record at all. That distinction matters, because it turns an unanswerable question ("will the algorithm like me?") into a checkable one: does my file extract the way I intend it to?

Here's the fastest way to check.

The two-minute test

Open your resume file — PDF or Word, doesn't matter — select all the text on the page, copy it, and paste it into a plain, unformatted text editor. Notepad on Windows, TextEdit set to plain-text mode on a Mac, or any code editor works. Don't paste into another word processor, since those can silently reformat things and mask the exact problem you're trying to see.

What lands in that plain-text window is a close approximation of what many parsers extract from your file: the raw characters, in whatever order the underlying document structure puts them in, with no styling, no columns, no visual layout to organize it. If it reads top to bottom in a sensible order, that's a good sign. If it doesn't, you're looking at roughly the same mess a parser would produce.

Go through your pasted text and check for these:

If everything on that list checks out, your resume's underlying structure is probably in decent shape. If two columns of content came out interleaved, or your contact details vanished, that's a specific, fixable problem — not a vague sense that something's "not ATS-friendly."

Why the order sometimes falls apart

The "reads top to bottom, left to right" description of ATS behavior is repeated so often it starts to sound like a fixed rule. It's closer to a default that holds only when your layout gives the parser one clear path to follow. A single column of text, one heading after another, does that naturally.

A multi-column resume doesn't. When a page has two columns side by side, a parser has to decide which one to read first, and different systems make that decision differently. Some finish the left column before starting the right; others advance line by line across the page, splicing unrelated content together. You genuinely can't tell from outside which behavior a given employer's system uses, which is the real argument for a single-column layout: it removes the ambiguity rather than betting on which kind of parser you'll hit. If you want the deeper mechanics of exactly when columns cause trouble and when they don't, that's covered in more detail in a companion piece on this site about multi-column resumes and ATS parsing.

Tables and text boxes cause a related problem for a related reason: the visual grid you see on the page isn't how the underlying file stores the content, so a parser reading the file's actual structure can end up with cell contents in an order that has nothing to do with how they're arranged visually.

The part the copy-paste test can miss

The Notepad test is genuinely useful, but it has a blind spot: page headers and footers. In both Word and PDF exports, header and footer content is often stored in a separate part of the file from the main body text — a different internal section, not just a different visual position. Depending on how you select text on the page, that content may or may not come along for the ride in your copy-paste test, and separately, not every parser is configured to read that section of the file even when it's present.

Nobody outside the companies building these systems publishes a full list of which platforms handle headers reliably and which skip them, so the practical guidance is simple regardless: put your name, phone number, and email in the regular body of the document, on the first page, not in a header or footer field. It costs you nothing, and it removes a variable you can't otherwise verify.

The other blind spot is scale. The plain-text paste tells you whether text extracts in a reasonable order. It doesn't tell you whether a parser correctly recognized "Experience" as a section header rather than just another line of text, or whether your phone number got correctly tagged as a phone number instead of landing as stray text nobody categorizes. That's a step beyond raw extraction, into how a system interprets what it extracted — and it's genuinely harder to check on your own, because it requires seeing the parsed output, not just the raw text.

Where this leaves you

The copy-paste test costs nothing and takes two minutes, and it catches a real category of problems: garbled reading order, glued-together words, contact info that silently didn't make it into the text at all. Do that first, on every version of your resume before you send it anywhere.

If you want to see the next layer down — whether your name and contact details actually get recognized as contact info, or whether your section headings get identified as sections rather than just floating text — that's the specific gap a parse-check tool is built to close. ResumeReadout runs that check for free, entirely in your browser (the file itself never leaves your device, and there's no signup to see the results): it shows you what got extracted and how it was categorized, not a synonym for a score. It's a narrower, more mechanical answer than a chatbot can give you, because a chatbot never sees your actual file — only whatever text you decide to paste in.

Either way, the underlying idea is the same: you don't have to guess what a parser does with your resume. You can go look.

FAQ

Is the copy-paste-into-Notepad test actually reliable?

It's a reasonable approximation, not a perfect match. Plain-text editors extract text roughly the way many parsers do, so if your resume comes out jumbled there, that's a real signal something in your layout is causing trouble. But some parsers behave differently than a generic text extractor, especially around headers, footers, and certain PDF export settings, so a clean paste is reassuring without being a guarantee.

Does an ATS read resumes strictly top to bottom, left to right?

Mostly, but it depends on the layout, not a fixed rule the software follows everywhere. A single-column page extracts in the order you'd expect. A multi-column layout is where that assumption breaks, because different parsers make different choices about which column to read first, and some interleave lines from both. That's the actual mechanism behind the "top to bottom" advice, not a universal law.

Should I ever put my contact info in a header or footer?

It's safer not to. Word and Google Docs both store header and footer content in a separate part of the file from the main body text, and not every parser is configured to look there. Putting your name, phone number, and email in the regular body of the first page costs you nothing and removes the question entirely.

If my resume passes the copy-paste test, is there anything else worth checking?

A couple of things a plain-text paste won't catch: whether your section headings use standard, recognizable labels (a heading styled as an image or an unusual label like "My Journey" instead of "Experience" can extract as text but still fail to get categorized correctly), and whether your contact details land in the fields a system expects, not just somewhere on the page. Those are more about categorization than raw text extraction, which is a step past what Notepad shows you.

Keep reading

Or skip the reading and run the free parse-check →