Why your PDF text extraction is garbled, out of order, or empty, and how to fix it
extracted PDF text has words run together or in the wrong order
Also appears as
- ligatures render as boxes or missing characters in extracted text
- multi-column PDF extracts columns interleaved line by line
- scanned PDF returns empty or gibberish text
Short answer
Garbled PDF extraction almost always comes from using a text-layer extractor on a document that does not have the kind of text layer it expects: scanned or image-based PDFs need OCR, multi-column layouts need layout-aware extraction to preserve reading order, and ligature characters need Unicode normalization. Match the extraction method to the actual document type, and route scanned engineering drawings to a vision model instead of text extraction entirely.
Affects: Any RAG ingestion pipeline handling mixed PDF sources: scanned documents, multi-column layouts, and typeset technical documents.
Fastest path to clean extracted text
- 1Check whether the PDF has a real text layer by attempting a simple text extraction; if it returns empty or near-empty text, the PDF is scanned images and needs OCR, not text extraction.
- 2For scanned documents, run OCR and validate output quality on a sample before batch processing the full corpus.
- 3For multi-column layouts, use a layout-aware extraction library or model that detects column boundaries and reading order, rather than a naive extractor that reads left-to-right across the full page width.
- 4Normalize ligature characters (fi, fl, ffi, ffl) and other Unicode substitutions during post-processing.
- 5For engineering drawings or documents where meaning is carried by spatial layout rather than linear text, route extraction through a vision-language model instead of forcing text extraction to handle content it was never designed for.
How to confirm this is your problem
- Extracted text has words or sentences run together with no spaces, or spaces inserted in the middle of words
- Reading a multi-column document produces text where lines from different columns are interleaved out of order
- Common letter combinations like fi, fl, or ffi are missing, replaced with boxes, or rendered as unrelated characters
- A PDF that opens and displays fine visually extracts as empty or near-empty text
- Engineering drawings or diagrams extract as scattered fragments of dimension labels with no coherent structure
Root causes and fixes
The PDF is a scanned image with no real text layer, and the extractor is not running OCR
Many PDFs, especially older documents, faxes, or scanned paperwork, contain only a rasterized image of each page with no embedded text at all. A standard text-extraction library looks for a text layer, finds none, and returns empty or minimal output, which is often mistaken for a bug rather than the expected result for an image-only document.
Fix: Detect scanned documents by checking for near-empty extraction results, then route them through an OCR engine before chunking, and manually spot-check OCR output quality since accuracy varies significantly with scan quality.
python -c "import fitz; print(len(fitz.open('doc.pdf')[0].get_text().strip()))"Multi-column layout is extracted in raw left-to-right, top-to-bottom order instead of true reading order
A naive text extractor processes text objects in the order they appear in the PDF's internal structure or by simple coordinate sorting across the full page width. For a two or three column layout, this interleaves lines from different columns, producing text that reads as nonsense even though every individual word extracted correctly.
Fix: Use a layout-aware extraction tool that detects column boundaries and extracts each column fully before moving to the next, or a document AI model trained on layout understanding.
Ligature glyphs are not correctly mapped back to their constituent characters
Many PDF fonts render common letter pairs like fi, fl, ffi, and ffl as single ligature glyphs for typographic quality. If the extraction library's font-to-Unicode mapping does not handle these glyphs, they extract as missing characters or unrelated codepoints, silently corrupting any word containing them.
Fix: Apply Unicode normalization and a known ligature substitution map as a post-processing step on all extracted text, and spot-check a sample for common words that frequently contain these ligatures.
Engineering drawings and diagrams are being forced through text extraction instead of a vision model
Drawings, schematics, and diagrams encode meaning through spatial arrangement, symbols, and dimension lines, not linear prose. Text extraction pulls out scattered labels and dimension numbers with no relational structure, which is technically correct extraction but useless for answering questions that depend on understanding what those labels refer to.
Fix: For documents where diagrams carry the primary information, use a vision-language model to describe or extract structured information directly from the rendered page image, rather than relying on the underlying text layer alone.
Diagnostic commands
Check if extraction returns meaningful text length for a supposedly text-based PDF
python -c "import fitz; d=fitz.open('doc.pdf'); print(sum(len(p.get_text()) for p in d))"A near-zero character count for a multi-page document strongly indicates a scanned, image-only PDF that needs OCR rather than a bug in the extraction code.
Visually compare extracted text order against the rendered page for a multi-column document
python -c "import fitz; print(fitz.open('doc.pdf')[0].get_text('blocks'))"Inspecting the block-level output with coordinates reveals whether blocks from different columns are being read in an interleaved order; layout-aware extraction should group and order blocks by column first.
Search extracted text for common ligature-affected words
python -c "import re; t=open('extracted.txt').read(); print(len(re.findall(r'o ce|of ce', t)))"Matches suggest ligature characters were dropped or mis-mapped during extraction, confirming a ligature normalization issue rather than a content problem.
Stopping it from happening again
- Automatically classify incoming PDFs as text-based or scanned before choosing an extraction method, rather than applying one extractor to everything.
- Run OCR quality checks on a sample of each new scanned document source before ingesting it at scale.
- Use a layout-aware extraction library for any document source known to use multi-column formatting.
- Apply Unicode normalization as a standard post-processing step on all extracted text, regardless of source.
- Route diagram-heavy document types through a vision model pipeline from the start, rather than discovering the failure after ingestion.
When this becomes an architecture problem
If your corpus includes a large volume of low-quality scans, handwritten annotations, or complex engineering drawings where even good OCR and vision models struggle with domain-specific symbols and notation, this becomes a document digitization and vision-model fine-tuning project rather than an extraction library swap, and is worth scoping with dedicated evaluation before committing to a single extraction approach across the whole corpus.
Frequently asked questions
How do I know if a PDF needs OCR without opening every file manually?
Run a quick text-extraction pass across the corpus and flag any document where extracted character count per page falls below a low threshold; pages below that threshold are very likely scanned images needing OCR.
Does OCR accuracy matter enough to pay for a commercial engine over open-source Tesseract?
For clean, modern scans, open-source OCR is often good enough. For low-quality scans, unusual fonts, handwriting, or documents where accuracy directly affects compliance or safety decisions, commercial OCR engines or vision-language models typically produce meaningfully fewer errors and are worth the cost.
Can a single extraction pipeline handle both scanned and native-text PDFs?
Yes, if it first classifies each document, or even each page, by whether it has a usable text layer, then routes scanned pages to OCR and text-layer pages to standard extraction. Trying to force one method to handle both reliably produces exactly the garbled or empty output this page describes.
Should engineering drawings be chunked and embedded like regular text documents?
Generally no, at least not from raw text extraction alone. Drawings usually need a vision-capable model to generate a textual description or extract structured data first, and that generated description is what gets chunked and embedded, since the original spatial information does not survive a text-only pipeline.
Size it properly next time
Free calculators that prevent this class of failure before you provision hardware.
Document Ingestion Pipeline Estimator
Estimate total pipeline time from document count, OCR share, and embedding throughput, so ingestion timelines stop being a guess in the project plan.
Free ToolRAG Chunking Strategy Calculator
Turn corpus size, chunk length, and overlap into a concrete chunk count, embedding cost, and vector storage footprint before you build the ingestion pipeline.
Free ToolRAG Accuracy Readiness Assessment
Score your retrieval-augmented generation system across eight dimensions that actually predict production accuracy, from chunking strategy to groundedness verification.
Related problems
Chunking splits tables and headers, destroying their meaning
Generic character-count or token-count chunking treats a document as an undifferentiated stream of text, so it routinely cuts a table's header row away from its data rows, leaving a retrieved chunk full of numbers with no column labels to explain what they mean. The fix is structure-aware chunking that detects table boundaries, keeps the header attached to every chunk of that table's rows, and never splits mid-row.
RAG retrieves irrelevant or wrong documents
RAG retrieves the wrong documents most often because the embedding model used to index the corpus differs from the one used at query time, or because chunks are large enough that a single embedding averages away the passage that actually answers the question. Fix embedding consistency and chunk granularity first, then add a reranker and metadata filters before touching the LLM prompt.
RAG citations point to the wrong source document
Wrong citations almost always come from a broken or ambiguous mapping between a retrieved chunk and its original source document, often introduced when chunks are re-ordered, deduplicated, or overlapped during ingestion without carrying a stable source id and offset through every processing step. Assign a stable, immutable id to every chunk at creation time, carry it through embedding, storage, retrieval, and generation, and verify at generation time that the cited id matches the chunk actually used.
GuideRAG Chunking Strategies: Fixed, Semantic, Structural, and Late
Compare RAG chunking strategies, fixed-size, semantic, structural, and late chunking, with concrete guidance on chunk size, overlap, and when each wins.
GuideEnterprise RAG Architecture: The Full 2026 Blueprint
A practitioner's blueprint for enterprise RAG in 2026: ingestion, chunking, embedding, retrieval, rerank, generation, and the eval loop that keeps it honest.
GuideRAG Evaluation Metrics: Recall@k, MRR, Faithfulness, and More
The RAG evaluation metrics that matter: recall@k and MRR for retrieval, faithfulness and answer relevance for generation, and how to build the eval loop.
Still stuck, or tired of fighting your own infrastructure?
Netray deploys and operates on-prem AI for regulated manufacturers and defense suppliers. We have debugged this stack in production, on air-gapped networks, at scale.