The two resume files that score zero before anyone reads them
The short answer
Two things can happen to a resume file that are not degradations. They are total. A password protected file and a file with no text layer are the only two checks in our published rule set worth 35 points each, and they are worth that because in both cases the software gets nothing at all.
Every other problem on the list is partial. A table confuses reading order. A header hides a phone number. Those are bad, and they cost you something specific. These two cost you the entire document, and the reason they are so dangerous is that your own copy looks completely normal when you open it.
Failure one: the file is locked
Some people protect a resume deliberately, usually while job searching from a work machine, or after a previous version leaked. Far more often it happens by accident. A document exported from a system that applies protection by default, or a PDF produced with permissions set on it, or a file inherited from a template that carried the setting along.
It does not matter which. When a parser opens an encrypted file it gets a sealed container. There is no partial read, no best effort, no salvaging the first page. The software cannot see a single word of your work history.
What makes this worse than it sounds is what happens next. Most application forms accept the upload without complaint. The file is valid. It uploads. You get a confirmation. Somewhere downstream a system stores a document it cannot read, and the field that should hold your experience is empty. Nothing tells you, because from the form's point of view nothing went wrong.
Failure two: there is no text in there
The second failure is more common and less understood. A resume with no extractable text is a resume that exists only as an image.
This happens in more ways than people expect. A resume that was printed and scanned back in. A resume exported from a design tool that outlined the type, which converts every letter from a character into a shape. A screenshot saved as a PDF. A file produced by a phone scanning app. In each case you end up with a document that looks exactly like a resume and contains none of the words in it.
A parser opening that file finds a picture. It has no name to read, no employer, no dates, no bullets. If the system does not run optical character recognition, and many do not, your application arrives carrying a blank.
Again, your copy looks perfect. You can read every word on your screen. The letters are there, as pixels. The difference between a letter you can see and a character a machine can select is invisible until something tries to select it.
How to check both in about ten seconds
There is a test that takes almost no time and settles both questions at once.
Open your resume. Try to select the text with your cursor, the way you would to copy a sentence. Then copy a line and paste it somewhere plain, like a blank note or an email draft.
If the file is locked, you will usually be asked for a password, or copying will be blocked outright. If the file has no text layer, your cursor will not select words at all. It will either do nothing or drag a selection box across the page as though you were selecting a photo. And if you can paste a clean line of your own resume into a blank note, both failures are ruled out.
That is the whole test. It requires no tool and no upload, and it catches the two most expensive problems on the entire list.
What to do when you find one
If the file is protected, the fix is to remove the protection and re-export rather than to strip it with a converter. Converters vary in what they preserve, and you can trade a locked file for a garbled one, which is a different problem covered in junk characters and decorative bullets.
Go back to the source document, whether that is a word processor file or a design file, confirm no protection or permission setting is applied, and export a fresh copy. Then run the select and paste test on the new file before you use it anywhere.
If the file is an image, you need the original. A resume that was scanned, or outlined, or screenshotted cannot be repaired into a text document by re-saving it. Running optical character recognition over it produces something readable but usually introduces its own errors, and those errors land in your name, your employer names and your dates, which are the fields with the least tolerance for a wrong character.
Rebuild from the source if you have it. If you do not have the source any more, retyping a two page resume is an hour of work that recovers 35 points and, more to the point, recovers the document.
Why this is worth more than layout advice
There is a great deal written about whether a resume is machine friendly, and most of it is about layout: columns, tables, fonts, spacing. Those things matter, and they are real checks with real weights. Multi column layout is 10 points, and we cover the actual risk in two column resumes.
But layout problems degrade a document. These two destroy it. A confused reading order still delivers your employer names to a recruiter, in the wrong order, but present. A locked file delivers nothing.
That is why they sit at the top of the published weights, and why they are the first thing to rule out before you spend an evening reformatting anything. There is no point perfecting the arrangement of text that no parser will ever see.
The general principle underneath
Both failures come from the same root: a resume is two different objects at once, and only one of them is visible to you.
There is the document you look at, which is a layout. And there is the document a machine reads, which is a stream of characters. Most of the time those two agree closely enough that you never think about the difference. Password protection and image only files are the two cases where they diverge completely, where the thing you see is perfect and the thing the software gets is empty.
Keeping that split in mind explains most of the rest of the list too. A header is visible to you and outside the body to a parser. A text box is visible to you and floating above the document to a parser. Every parse check on the list is a place where what you see and what gets read part company.
If you want to see which of them apply to your specific file, the free ATS checker runs the whole published rule set in your browser and shows each finding against the line it refers to. Nothing is uploaded and no account is required. For the full ranked list of what those checks are and what each costs, start with what actually breaks a resume in an ATS. And once the file is sound, the question of whether to keep one resume or several is worth its own answer, which is in one resume or several versions.
The free ATS checker built by iapplyai.app catches both of these before an employer's system does, in your browser, with nothing uploaded and no account needed. It takes about as long as the copy and paste test and it names the finding rather than leaving you to infer it.
