A PDF has a text layer if the characters are stored as actual text inside the file — which is true for almost every digitally created PDF: bank statements, invoices, contracts, exports from Word or a browser. A scanned PDF is just pictures of pages, and turning pictures into text requires OCR (optical character recognition). The quickest test: open the PDF and try to select the text. If you can select and copy it, there’s a text layer. If your cursor draws a box on the page, it’s an image.
This one distinction decides which tools work, what the conversion costs, and how much you can trust the output.
Why the distinction matters
| Text-layer PDF | Scanned PDF | |
|---|---|---|
| What’s inside | Real characters with positions | Page images |
| Extraction method | Deterministic text extraction | OCR or a vision model |
| Accuracy | Exact — the characters are the source | Probabilistic — models guess characters |
| Speed & cost | Milliseconds, cheap CPU work | Slower, GPU or paid vision API |
| Failure mode | None for the text itself | Misread digits, hallucinated words |
The failure-mode row is the one that bites. OCR errors concentrate in exactly the places that matter — 0 vs O, 1 vs l, decimal points in amounts. If a document has a text layer and you run it through OCR or a vision model anyway, you’re paying more to get a less reliable copy of text the file already contains.
How to check for a text layer programmatically
In Python, with pypdf:
from pypdf import PdfReader
reader = PdfReader("document.pdf")
text = "".join(page.extract_text() or "" for page in reader.pages[:3])
has_text_layer = len(text.strip()) > 50 # a real text layer yields real content
Or use the API you were going to convert with anyway: POST the file to marklipi, and a 422 response is the answer — it means no usable text layer was found, so route that file to OCR. A 200 means you just got the Markdown, so the check and the conversion were the same request.
curl -s -o /dev/null -w "%{http_code}" https://api.marklipi.com/convert -F "file=@document.pdf"
# 200 → text layer, Markdown returned · 422 → scan, needs OCR
The right pipeline routes documents, not one-size-fits-all
A robust document pipeline treats extraction as a routing decision:
- Try text-layer extraction first. It’s fast, cheap, and exact. The overwhelming majority of business documents — statements, filings, invoices, contracts — are digital-native and take this path.
- Fall back to OCR only on
422. Tesseract for simple scans; a vision model for handwriting, photos, or degraded scans. - Never OCR what has a text layer. It’s slower, costlier, and strictly less accurate.
Tools that run OCR on everything hide this decision from you — and quietly charge vision-model prices for documents that needed a text read. Tools that only do OCR make the opposite mistake. marklipi deliberately does text-layer extraction only and returns a clean 422 for scans, so the routing decision stays visible and cheap. (Comparison of both kinds of tools: best PDF-to-Markdown tools.)
FAQ
Can a PDF be both?
Yes — a scanned PDF that someone already ran OCR on has an (imperfect) text layer sitting over the page images. Extraction will return that OCR text, including its errors. If the numbers must be exact, check the document’s provenance.
Are password-protected PDFs a text-layer problem?
No, encryption is separate. A decrypted digital PDF still has its text layer; a decrypted scan still doesn’t.
My PDF has selectable text but extraction comes out garbled. Why?
Rare, but it happens: some PDFs use custom font encodings that map glyphs unusually (common with certain generators and subsetted fonts). The text renders correctly but extracts as gibberish. Those files effectively need OCR despite having a “text layer.”
What fraction of PDFs actually need OCR?
For digital-native business workflows (banking, legal, SaaS exports), the large majority of PDFs have text layers. OCR-dependent corpora are typically archives, government scans, and paper-first industries.