Is Your Resume ATS-Friendly? Check How It Parses With Tools You Already Have

Check 1: the copy-paste survival test

This is the fastest and most informative thing on the list, and it takes ninety seconds. Open your resume PDF in any viewer. Press select all (Cmd+A on macOS, Ctrl+A on Windows), copy, and paste into a plain-text box - Notepad, or TextEdit after Format > Make Plain Text. What you get back is close to what a text extractor sees.

Count these five things in the pasted text:

• Is your name and contact line there as text, or did it arrive as nothing, because that block is an image rather than text?
• Does every job title and employer appear, or did a header inside a text box vanish?
• Are the dates still readable as dates - "Mar 2022 - Present", not a string of fragments?
• Did any skill row that was an image or an icon bar survive at all? A five-dot proficiency graphic is not text.
• Are there lines of nothing where a table cell or a text column used to be?

Anything missing from the paste is missing for every reader that goes through the text layer first. That includes a human using a screen reader, which is the same failure with a much bigger consequence than a job application.

Check 2: reading order, which is where two columns bite

Take the pasted text from Check 1 and read it in the order it came out. A one-column resume almost always extracts top to bottom the way you wrote it. A two-column resume can reorder. In the files I sell the sidebar is first in the document, so the extracted text opens with contact details and skills and the name arrives after them - which is a property of the file, not of a reader. What order a given system imposes on a two-column PDF is a question about that system, and I have not put any of mine to one.

The check is specific: find the line where your Skills block starts in the pasted text, and note how far it is from the Skills heading you can see in the PDF. If the distance is large or the block is split, extraction reordered it. Two columns are not disqualifying - they are a thing you should know before you submit, so you can decide whether the layout is earning its risk.

Check 3: one heading vocabulary per document

Look at your section names as a set. "Experience", then "Work History", then "Professional Background" in one file is three names for one thing. Consistency matters for the plain reason that a human skimming for a job title should find it in the place they expect, and a text extractor has no idea that your three labels mean the same section.

I ran this measurement on my own templates rather than asserting it: the three files in the pack use three heading vocabularies between them, which is fine across separate files you choose between and would be sloppy inside one document. Pick one set - Experience / Education / Skills is the boring, widely used one - and use it in the file you send.

Check 4: does the file reach outside itself?

A resume that pulls a font, an image or a stylesheet from a URL renders differently depending on whether the person opening it has network access, and the text layer may come out with substitutions you never chose. You can check this on a copy of the file in a text editor: look for http://, https:// and @import inside the document source, and for url( in any embedded stylesheet.

If you author in HTML - which is what my own templates are, printed to PDF from a browser - this is a one-line search. Measured on the three templates plus the cover letter in the pack: 0 network references. Nothing has to be fetched to open the file, so it behaves the same with the network off - a stability property, not a promise about how it prints on someone else's machine (the shipped README goes further: one of the three templates needs "Background graphics" ticked at print time to keep its sidebar colour).

Check 5: know what a free checker actually inspects

Free "ATS resume checkers" are, with depressing consistency, one of two things: a keyword-density report against a job description you pasted in, or a file-format lint that flags columns, graphics and unusual headings. Both are useful. Neither is a test against the parser your target employer uses, because nobody outside that employer can run it.

So read a checker's output for what it inspects and what it guesses:

• Inspects: whether text is selectable; whether common section names exist; keyword overlap with a description; file size and page count.
• Guesses: whether any particular applicant-tracking system accepted the file; what "score" means; whether a layout "passes".
• Costs you: your name, phone number, email and employer history, uploaded to a site whose business is usually selling you the full report. That is a real trade, and it is not required for checks 1-4.

I have not run my files through any scanner, so I will not tell you what one would say. The pack's own listing says the same thing: 0 scanner tests. What the files do contain is measurable on your machine in ten minutes: selectable text, one heading vocabulary per document, no external references, print-to-PDF from a browser.

What these checks cannot tell you

• Not whether you will get interviews. Most rejections are about fit and competition, not file format. What you can settle in ten minutes is what your file's text layer contains; whether a particular reader calls that a clean parse is not yours to control, and nothing here has been tested against one. It is not the whole battle either, and pretending otherwise would be a sales pitch.
• Not whether any specific system accepts your file. Every employer's setup differs and none of them publishes its parser's behaviour. Anyone claiming a file "passes every ATS" is selling something you cannot verify - which is exactly why this post only lists things you can verify yourself.
• Not a substitute for the plain human read. A hiring manager spends seconds on the first pass. If your most relevant win for the job is not in the top third of page one, no formatting fix will rescue it.