> Bron: https://neuralex.nl/en/blog/rag-over-pdf-en-scans > Scanned PDFs make RAG systems vulnerable to extraction errors. Learn why OCR, tables and complex layouts cause problems and how to validate documents before indexing them. [Back to Insights](/en/blog) RAG ·6 October 2026 ·6 min read # RAG over PDFs: why scans are your biggest enemy Scanned PDFs make RAG systems vulnerable to extraction errors. Learn why OCR, tables and complex layouts cause problems and how to validate documents before indexing them. Scans are among the most difficult source documents for a RAG system because a scanned PDF often contains no actual text. What looks like a normal page to you may technically be nothing more than an image. Without additional processing, a RAG pipeline cannot reliably retrieve, split or index the words shown on that page. The solution therefore starts before the vector index: first determine whether the PDF contains a usable text layer and apply OCR when it does not. Do not automatically treat OCR output as trustworthy source text. Validate the extraction, preserve its relationship with the original page number, and only index questionable documents once you know the extracted text is sufficiently accurate. ## A PDF with a text layer is different from a scan A PDF is primarily a container format. Two files that look almost identical on screen can be constructed in very different ways. A digitally generated PDF usually contains text elements that software can select and read directly. That text layer can relatively easily be used as input for a RAG system. A scanned PDF, by contrast, may consist of one image for each page. The page contains visible pixels, but no individual letters, words or paragraphs that extraction software can access directly. The text first has to be inferred from the image using optical character recognition, or OCR. This distinction matters because RAG depends heavily on source extraction quality. The rest of that process is explained in [RAG explained](/en/blog/rag-uitgelegd). If information is already damaged during the first extraction step, later stages of the pipeline usually cannot fully reconstruct it. ## OCR makes text usable, but not automatically correct OCR attempts to recognise visual shapes on a page as letters, words and sometimes structural elements. Clear, straight scans of well-printed material can produce useful text. Reliability, however, varies considerably between documents and between OCR systems. Low image quality, stains, faded print and compression artefacts can interfere with recognition. The same applies to skewed pages, handwriting, stamps, signatures and text printed over background graphics. Multi-column documents also create problems when an extractor fails to identify the correct reading order. Headers and footers may be inserted repeatedly into the extracted text on every page. Document titles, page codes or disclaimers can therefore appear between paragraphs throughout the document. A human reader ignores these elements almost automatically, but a text-processing pipeline simply sees additional tokens. ## OCR errors propagate into chunks, embeddings and citations An OCR error does not necessarily remain an isolated spelling mistake. It becomes part of the text on which the rest of the RAG pipeline is built. During [chunking](/en/blog/chunking-uitgelegd), incorrectly recognised paragraph boundaries can cause content to be split or combined in inappropriate places. Those chunks are then converted into embeddings. A single OCR error may have little effect on semantic meaning, but larger extraction failures can materially change what a chunk represents. Missing negations, mixed-up columns or incorrectly recognised numbers can all distort the information. The retriever may consequently return a less relevant passage or fail to retrieve a relevant one. Citations also become harder to verify. If the RAG system quotes a passage that has been corrupted during extraction, the user may not be able to find the same wording in the original document. For that reason, preserve the relationship between each extracted passage and its original document and page number. A filename alone is often not precise enough for validating information in longer documents. ## Tables and forms require more than plain text Tables create a separate class of problems. A basic text extractor may read cells one after another without preserving which value belongs to which row or column. A table containing amounts, dates or product attributes can therefore turn into a sequence of unrelated words and numbers whose original relationships have disappeared. Forms have a similar weakness. Their meaning often depends not only on the entered value but also on the associated label, field position and possibly a selected checkbox. If an extractor returns only loose text, it can become unclear which answer belongs to which question. Layout-aware extraction can therefore be more suitable than simply converting a page to plain text. A layout-aware extractor attempts to recognise text blocks, columns, tables and other page elements as part of the document structure. This does not solve every document reliably, but it gives the RAG pipeline more information with which to preserve the original relationships. For tables, it may sometimes be better to convert their contents into a structured representation rather than treat them as ordinary paragraphs. The appropriate approach depends on the document type and on the questions the system will later need to answer. ## Validate the extraction before indexing Successfully passing a document through an OCR or extraction tool is not the same as performing quality control. Before text enters a vector index, you should verify that the extracted content still represents the original document with sufficient accuracy. A practical checklist: - Automatically determine whether a PDF contains a text layer or mainly consists of images. - For scanned files, compare a sample of the OCR output directly with the original pages. - Give additional attention to documents containing tables, columns, forms, stamps or handwriting. - Check that headers, footers and page numbers are not unnecessarily repeated in every chunk. - Store the document name and original page number as metadata with the extracted text. - Flag documents with questionable extraction quality so they are not silently treated as normal sources. - After indexing, test questions for which you know where the correct answer appears in the source document. A stable evaluation set helps determine whether changes to extraction, OCR or chunking improve or degrade retrieval quality. See [how to measure RAG quality](/en/blog/rag-kwaliteit-meten) for the wider evaluation process. When a system moves into production, document quality should become part of normal operational control rather than a one-time import concern. ## Sometimes a document should not be indexed Not every document needs to be forced into the knowledge base. If a scan is barely readable, contains extensive handwriting or has a layout that is consistently misinterpreted, excluding it from the index can be safer than making poor-quality text available as a supposedly reliable knowledge source. Manual review becomes particularly important when small extraction errors can materially change meaning. This includes contractual clauses, forms, monetary values, dates and documents in which tables contain the essential information. A language model can process damaged extracted text fluently without knowing that the source itself was corrupted. A technically successful RAG query can therefore still produce an unreliable answer. The main rule is simple: treat document extraction as a separate quality stage. RAG does not begin with embeddings or a vector database. It begins with a reliable representation of the original document. With scanned PDFs, that reliability first has to be created and verified before you allow the model to depend on it. RAG in practice ## Are your most important documents sitting in a folder as scans? We assess extraction quality first and only then build the index — so answers and source citations hold up. Curious what that means for your documents? [Ask your question](/en/contact) [Read how RAG works](/en/blog/rag-uitgelegd) --- Volledige (opgemaakte) versie: https://neuralex.nl/en/blog/rag-over-pdf-en-scans