RAG over PDFs with n8n: extract, chunk and query your documents

Contracts, reports, technical manuals, invoices: company knowledge overwhelmingly sleeps inside PDFs. A RAG assistant able to answer "what does clause 7 of the Dupont contract say?" while citing the exact passage is one of the most requested n8n use cases — and one where implementation details make all the difference. This guide covers the full pipeline: text extraction (including scanned PDFs), format-aware chunking, vector indexing and querying, with the traps specific to the PDF format.

The pipeline in four steps

A PDF RAG in n8n always follows the same skeleton:

1. Fetch the files: a Google Drive trigger (new file in a folder), a Dropbox node, an inbound email with an attachment, or a watched folder on self-hosted.
2. Extract the text: the Extract from File node (Extract From PDF operation) returns the text layer of the PDF.
3. Chunk and vectorize: a text splitter, an embedding model, then insertion into a vector store (Qdrant, Supabase/pgvector, Pinecone…).
4. Query: an AI Agent or a Question & Answer chain plugged into the same vector store, with a chat node or a webhook up front.

Steps 3 and 4 are common to every RAG — our guides on document chunking and choosing an embedding model apply as-is. What changes with PDFs is step 2: extraction, where the quality of everything else is decided. The founding principle of RAG — giving the model access to an external document base rather than relying on its memory — comes from the work of Lewis and co-authors published in 2020 (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks); everything below is its hands-on application to the least cooperative file format around.

Extract from File: what the node can (and cannot) do

For a native PDF — produced by a word processor, an accounting export, an invoice generator — Extract from File is enough: it reads the embedded text layer and returns it in a text field, along with the page count and document metadata. Useful settings: Join Pages to get a single block of text instead of one per page, and Max Pages to cap processing on very long documents.

What the node cannot do:

• Scanned PDFs: a scan is an image, there is no text layer to read. The node returns an empty or near-empty string — which happens to be the best automatic test to route the document to OCR (an IF node on the extracted text length).
• Layout: multiple columns, boxes, footnotes come out in a sometimes surprising order.
• Tables: cells are flattened line by line, and the mapping to headers is lost.

Scanned PDFs: the OCR stage

For scans, an optical character recognition stage is required before indexing. Three options depending on context:

Option	Type	Strengths	Worth knowing
Mistral OCR / vision LLM API	Cloud API	Excellent quality, outputs Markdown (headings, tables)	Per-page cost, data sent to a third party
Google Document AI	Cloud API	Very robust on administrative documents	Heavier GCP setup
Tesseract (self-hosted)	Open source	Free, data stays home	Weaker on degraded scans, no structure

OCR quality is not a cosmetic detail: information-retrieval research on OCRed corpora — notably the work of Taghva, Borsack and Condit published in 1996 (Evaluation of model-based retrieval effectiveness with OCR text) — shows that retrieval withstands moderate OCR errors surprisingly well, but degrades sharply on short documents or poor-quality scans, exactly the profile of scanned invoices and letters. A simple quality check (share of non-alphabetic characters, out-of-dictionary words) after OCR keeps noise out of the index.

Chunking PDFs: follow the structure

Character-based splitting works, but professional PDFs almost always carry an exploitable structure: contract clauses, numbered sections, headings. If your extraction stage outputs Markdown (as modern OCR services do), a splitter that cuts on headings produces chunks that map to units of meaning — a clause, a section — and retrieval relevance improves immediately.

Two complementary PDF-specific settings:

• Citation metadata: store file_name, page and if possible the section in each chunk's metadata. That is what lets the assistant answer "Dupont contract, page 12, clause 7" instead of an unverifiable claim — and it is the foundation of metadata filtering.
• Cap the number of retrieved chunks: no point sending 20 chunks to the model. The work of Liu and co-authors published in 2023 (Lost in the Middle: How Language Models Use Long Contexts) shows that models make poor use of information buried in the middle of a long context: 4 to 6 well-ranked chunks — possibly via reranking — beat 20 raw ones.

The ingestion workflow, concretely

The ingestion skeleton to reproduce in n8n:

1. Google Drive Trigger — On new file in folder, filtered on application/pdf.
2. Google Drive — Download file (the trigger only provides metadata).
3. Extract from File — Extract From PDF, Join Pages enabled.
4. IF — {{ $json.text.length > 100 }}: true → main pipeline; false → OCR branch, then back into the main flow.
5. Vector Store (Qdrant/Supabase) — Insert documents, with a Default Data Loader carrying the metadata (file_id, file_name, page) and a text splitter set to 800 tokens / 15% overlap.

On the query side, an AI Agent with the Vector Store tool plugged into the same index is enough; the system prompt must require the file and page to be cited for every claim. For corpora mixing exact references (clause numbers, codes) with natural-language questions, hybrid search combining BM25 and vectors makes the difference, and evaluating your RAG's quality against a reference question set will tell you whether the pipeline delivers.

The PDF-specific traps

• Version duplicates: without an update strategy keyed on file_id, every new version of a contract coexists with the old one in the index — and the assistant cites the obsolete one. See our guide on updating a RAG index.
• Repeated headers and footers: "Company X — Confidential — page N" repeated 40 times pollutes the embeddings. A regex cleanup at ingestion (identical lines present on more than half the pages) solves it.
• Protected PDFs: an encrypted or copy-protected PDF makes extraction fail. Plan an error branch that notifies you rather than a workflow that stops silently.
• Extracting ≠ understanding: for fixed-structure documents (invoices, purchase orders), RAG is a detour — a direct AI-driven structured extraction into validated JSON is more reliable and cheaper.

Key takeaways

A PDF RAG in n8n requires no exotic component: Extract from File for native PDFs, a conditional OCR stage for scans, structure-aware chunking, systematic citation metadata. Quality is decided at ingestion — that is where to invest, since the rest of the pipeline is identical to any well-built RAG.