Why your PDF converted to half-empty text (and how to tell before you convert)

If your PDF came out with the first part full of text and the rest blank, nothing broke. Those blank pages have no text layer: they are pictures of words, not words. Every converter that reads a PDF's text layer, this site included, returns nothing for them, because there is nothing to read. To find out in ten seconds which pages are affected, open the PDF and press Ctrl+F (Cmd+F on a Mac) and search for a word you can plainly see on a blank-output page. If the search finds nothing and you cannot select the text with your cursor, that page is an image. From there you have three routes: run OCR to create a text layer, convert the PDF to JPG images so you keep the pages exactly as they look, or go back and get the original digital file. Each is covered below.

This is by far the most common reason a PDF conversion looks broken, and it catches people out most on the exact document you probably have: a contract or application where the first pages were typed and the later pages are scans of something signed or photocopied.

What a text layer actually is

A PDF page is a set of drawing instructions. When a document is created digitally, by exporting from Word, printing to PDF from a browser, or compiling with LaTeX, each piece of text is stored as a real text-drawing operation: this glyph, from this font, at these coordinates. That collection of operations is the text layer. Extraction tools walk it and reassemble the reading order.

When a page comes from a scanner, a photocopier, or a phone camera, the PDF contains exactly one drawing instruction: paste this image here, full page. The words in that image are pixels. There is no font, no glyph, no coordinate, and nothing for an extractor to walk. The page is a photograph that happens to be stored in a PDF container.

Both kinds of page can sit in the same file, which is where the confusion comes from. A PDF is a container, not a format guarantee. Nothing about the file extension, the file size, or how the document looks on screen tells you which pages are which. That is why "the first half worked and the second half didn't" feels like a bug: visually the pages are indistinguishable, so the output looks arbitrary.

Three ways to check, from fastest to most precise

Select the text. Try to drag-select a sentence on the page. If a text cursor appears and a blue selection follows your drag, there is a text layer. If your cursor draws a marquee box over the page like you are cropping an image, there is not.

Search the document. Ctrl+F for a word you can see on the page. This is the fastest check for a mixed file, because you can quickly establish that a word on page 2 is findable and the same word on page 9 is not.

Ask the file directly. If you have the Poppler utilities installed (brew install poppler on macOS, apt install poppler-utils on Debian or Ubuntu), pdffonts lists every font a PDF embeds:

pdffonts document.pdf

A digital PDF prints a table of font names. A fully scanned PDF prints only the header row and nothing else, because a page of pixels needs no fonts. For a page-by-page view, pdftotext writes what the text layer holds, with a form feed between pages:

pdftotext document.pdf - | less

The pages that come back empty here are exactly the pages that will come back empty from any browser-based converter. That is the useful part: it confirms the problem is the document, not the tool.

Route 1: OCR, when you need the words back

Optical character recognition looks at the picture and guesses the characters. Modern OCR on a clean 300 DPI scan of ordinary printed text is very good. On a faxed, skewed, low-contrast photocopy, or on handwriting, it is much less good, and it fails quietly by producing plausible but wrong characters rather than by refusing.

The tool worth knowing is OCRmyPDF, which wraps Tesseract and does the right thing by default: it adds an invisible text layer underneath the existing page image, so the document still looks identical but becomes searchable and extractable.

ocrmypdf --skip-text input.pdf output.pdf

--skip-text is the flag that matters for a mixed document. It leaves pages that already have a text layer untouched and only OCRs the ones that do not, which is both faster and safer than re-processing pages that were already perfect. For a non-English document, add the language pack, for example -l chi_sim for simplified Chinese or -l deu for German.

Once output.pdf exists, it has a text layer on every page, and converting it to plain text or to markdown will produce full output.

Two honest caveats. OCR output needs proofreading before you rely on it for anything consequential, especially numbers, where a 6 read as an 8 is invisible in a way a misread word is not. And OCR of a table rarely reconstructs the table structure, so if you are aiming at a CSV of a scanned table, expect to fix the columns by hand.

Route 2: keep the pages as images

Often you do not actually want the text. You want the pages, in order, as files you can attach, upload one at a time to a form, or drop into a slide. In that case OCR is a detour that also degrades what you have.

Converting the PDF to JPG renders every page, text pages and scanned pages alike, and gives you back page-001.jpg, page-002.jpg and so on in a ZIP. Because it rasterises rather than extracts, the mixed-document problem disappears completely: a page that is already an image and a page of live text both render to the same kind of output. This is the right route for a photocopied set of records, an application packet that has to be uploaded page by page, or anything where fidelity to the original appearance matters more than editable words.

Route 3: go back for the original

The most reliable fix is the one people skip. A scanned page exists because someone printed a digital document and scanned it back in. That digital original still exists somewhere: in the sender's outbox, the system that generated the statement, the shared drive the form came from. Asking for the .docx, the original PDF export, or a CSV of the data behind a printed table takes a message, and it beats any amount of OCR cleanup. Ask before you spend an hour correcting recognition errors.

Why we show which pages are affected

Silently returning a half-empty file is the part we consider a real defect, and it is the part we fixed. When a mixed PDF is converted here, the result now carries a warning naming the pages, in this shape:

8 of 20 pages have no text layer (page 5-12). Those pages are scanned or image-only, so they come out empty here. There is no OCR; to keep them, convert the PDF to JPG instead, or run it through an OCR tool first.

Previously the check was one flag for the whole document, so a file with any text at all counted as fine and the output looked like a conversion failure. Naming the page numbers changes the message from "this tool is broken" to "pages 5 to 12 of your document are photographs", which is a fact about the file that you can act on.

PDFMoka has no OCR and will not claim otherwise. Everything here runs inside your browser with nothing uploaded, and a recognition engine capable of handling real scans well is not something we can honestly ship under that constraint today. Stating the limit is more useful than hiding it behind a blank page. If you need the words from a scan, use OCRmyPDF locally; if you need the pages, convert to JPG and keep them exactly as they are.