Put two PDFs next to each other on a screen and they can be, to the eye, the same document. Same typeface, same margins, same crisp black letters on the same white page. Zoom in and both stay sharp. Print them and you’d get two identical sheets. By every test your eyes can run, they are the same file.
Then you press Cmd+A on each. One lights up blue, every word selected, ready to copy. The other selects nothing — not a word, not a letter — because there is nothing there to select. It isn’t a page of text that happens to be hard to grab. It’s a picture of a page of text: a photograph, flattened, with no letters in it at all, just the memory of where letters were. The first file has a text layer. The second is a scan wearing one’s clothes.
That difference is invisible right up until it’s the only thing that matters.
The layer you can’t see
A born-digital PDF — exported from a word processor, a design tool, a browser — carries the actual characters. The glyphs on screen are drawn from text, so the text is still in there: selectable, searchable, copyable, readable by a screen reader, extractable by whatever system you submit it to. A scanned PDF is the opposite. A camera or a scanner turned the page into a raster image, and that image got wrapped in a PDF. What you see is a photo. Cmd+F finds nothing. A screen reader finds silence. The words are depicted, not present.
The trap is that the two look identical, and the good-looking one is often the broken one. A pristine 600-dpi scan of a signed contract looks more “official” than a plain export — and it’s the one that will fail. The quality of the picture has nothing to do with whether there’s text underneath it, and your eyes are only ever judging the picture.
A scan can be beautiful and still be empty. The eye grades the photograph; the requirement is about the layer under it — and the two have never once agreed to match.
Where the empty page gets caught
For a long time this didn’t cost most people anything, because the only reader was a human, and a human reads the picture just fine. That’s changed. The systems a finished document has to pass through now read the layer, and they are unforgiving about it.
Court e-filing portals increasingly require that filings be text-searchable — an image-only PDF is rejected at the door, or accepted and then flagged, because a clerk can’t run a search across an exhibit that’s secretly a photograph. Academic and grant submission systems parse your text to check references and run similarity tools; feed them a scan and they see a blank. Accessibility law treats an image-only document as unreadable, because to a blind reader using a screen reader, it genuinely is. And every retrieval system built in the last two years — search, indexing, the model that’s going to answer a question from your document later — needs the characters, not the snapshot. To all of them, the gorgeous scan is a page with nothing written on it.
None of these tell you kindly. The best case is a curt rejection at upload. The worse case is that the file goes through, looks fine to every human who opens it, and silently fails to be findable for as long as it exists — a citation no search will ever surface, an exhibit no one can quote.
Preflight looks where the form looks
Preflight checks a PDF against the things a submission system actually measures, and searchable text is one of them — sitting right alongside the exact byte ceiling, the page count, and encryption. Where most tools show you a preview — a picture of the document, the very thing that’s already lying to you — Preflight goes past the render and asks the file the question the form is going to ask: is there text in here, or just an image of text?
So it reads the text layer, not the picture. It walks the pages, pulls the characters each one actually contains, and reports what it found the same honest three-column way it reports everything else: here is the observed value — words extracted, pages with a real text layer, pages that are image-only — here is the requirement, here is the verdict. A file that’s fully searchable passes clean. A scan comes back flagged: image only — no extractable text. Not “looks fine.” Not a thumbnail that shows you the photograph and lets you draw your own wrong conclusion. The actual state of the layer, named before you submit rather than discovered by the portal after.
And it does the looking on your Mac. Reading the text layer of a document — often the whole confidential document, the contract or the filing or the record — is exactly the kind of thing you don’t want to hand to someone else’s server, which is why there’s no network code in the app at all. The page never leaves your machine to be told what’s on it.
The check that doesn’t trust your eyes
The thread running through everything Preflight does is a refusal to grade a document the way a glance does. The byte check exists because “about 5 megabytes” isn’t what the form counts. This check exists for the same reason one level down: “it looks like text” isn’t what the form reads. A preview is a rendering, and a rendering is the one view of a PDF that cannot tell you whether the thing you’re about to submit is a document or a photograph of one.
The reason we only build what we run is that we’re the ones who’d have to answer for a tool that said a file was ready when it wasn’t. A checker that trusts the picture is worse than no checker — it launders a bad file into a confident one. So Preflight declines to look at the page the way you do. It selects all, and it counts what actually came back. On one file that’s every word. On the other it’s nothing — and the whole point is to find that out here, on your desk, and not from a rejection notice with your name on it.