I asked Claude Code to pull the key dates out of a PDF I had saved from a webpage. It came back immediately:
Which was strange, because I had the PDF open on my other monitor and it was four and a half megabytes of perfectly legible text.
The interesting part is not that it was wrong. The interesting part is that nothing had failed. Every component in that chain did exactly what it was designed to do, reported success, and stacking those successes together produced a lie I believed.
I was preprocessing documents with markitdown, Microsoft's file-to-markdown converter, so I ran it by hand:
Exit code 0. Zero-byte output file. No warning, no stderr, nothing on the console at all.
My integration did what integrations do: checked the return code, saw success, cached the result, and handed the model a path to a file with nothing in it. The model read the file, found nothing in it, and told me the document was empty. From its position that was a reasonable conclusion. It had been given an empty file and told the conversion worked.
My first instinct was to file an issue. I am glad I did not, because markitdown is behaving correctly and I would have been publicly wrong.
The PDF was a full-page browser screenshot exported to PDF. It contains raster images and no text layer whatsoever. pdfminer reports 0 characters, and so does PyMuPDF when you ask it. markitdown's PDF backend extracts embedded text and does not OCR — that is a documented design decision, not an oversight.
So there was genuinely nothing to find. And finding nothing is not an error. A converter that exited non-zero every time a document happened to be empty would be wrong in a much more annoying way.
Exit code answers "did the process complete?" I was reading it as an answer to "did we get the text?" Those are different questions, and for a document converter meeting a scanned page they have different answers. Mine was one of those integrations. Probably yours is too — pdftotext, pandoc and most extraction tooling have the same shape, because they should.
Simple to say. The trouble starts immediately, because "measure the yield" needs a threshold, and thresholds are where honest engineering goes to become arbitrary. Anyone can write if len(text) == 0: fail. That catches the screenshot. It does not catch the case that actually cost me time.
A course completion certificate. One page, a decorative graphic, and a title line rendered as real text. It converts to this:
Thirty-nine characters. Not zero. It sails through an emptiness check, gets cached as a successful conversion, and the model dutifully reports that your certificate says "Certificate of Completion" and nothing else — which is, again, technically what it was given.
That is the shape of the real problem. The fully-empty case is easy and any check catches it. The expensive failures are the near-misses: a certificate, a slide deck exported as page images with a footer on every slide, a contract scanned at an angle with a header that happened to OCR at some point. They all return some characters.
So the question becomes: how do you tell "extraction failed" from "this document is legitimately short"?
The obvious move is a minimum size — reject anything under, say, 500 bytes. It does not work, and the reason it does not work is worth being precise about: raw byte count conflates document length with extraction quality.
800 bytes is a complete and correct conversion of a one-page memo. 800 bytes from a 200-page report is a catastrophic extraction failure. The same number means opposite things and the measure cannot distinguish them.
What you want is density, not volume. Characters per page normalises document length away and leaves only the question you actually care about: on each page, did we recover a page's worth of text?