How to Parse PDFs and Documents for LLM Applications

Why Document Parsing Is Hard

A PDF does not contain paragraphs, headings, and tables as structured elements. It contains a sequence of drawing instructions: place this glyph at coordinates (x, y) using this font at this size. The concept of a paragraph is visual, a block of text with consistent left margin and line spacing, not semantic. The concept of a table is spatial, text aligned in rows and columns defined by invisible grid lines, not structural. Reading order is implied by position on the page, not encoded as a sequence.

This means that extracting text from a PDF in the correct order with the correct structure is fundamentally a computer vision problem, not a text processing problem. A simple extraction library that reads the glyph coordinates and outputs them left-to-right, top-to-bottom will produce garbled output for any document with columns, headers, footers, sidebars, or figures that interrupt the text flow. The text from column one will interleave with text from column two. Headers and footers will appear mid-paragraph. Table cell text will run together without cell boundaries.

Word documents (DOCX) are easier because the format explicitly encodes paragraphs, headings, lists, and tables as XML elements. A DOCX parser can extract structured text with correct element types by reading the XML directly, without needing to infer structure from visual layout. The challenge with DOCX is handling embedded objects (images, charts, equations) and tracking changes (revisions that show both old and new text), but the basic text extraction is reliable.

PowerPoint (PPTX) presents a different problem: each slide is a collection of text boxes positioned freely on a canvas. There is no guaranteed reading order, no inherent hierarchy between text boxes, and the important information might be in bullet points, speaker notes, or embedded tables. Extracting coherent text from a presentation requires deciding which text boxes contain the main content, what order to read them in, and whether to include the speaker notes (which often contain more detail than the slides themselves).

Simple Text Extraction

Simple text extraction uses libraries that read the internal structure of document files and output raw text. For PDFs, this means libraries like PyPDF2, pdfplumber, and pdfminer.six. For DOCX, python-docx. For PPTX, python-pptx. These libraries extract text reliably from straightforward documents but struggle with complex layouts.

PyPDF2 is the simplest option for PDFs. It reads the text objects from each page and concatenates them, which works for single-column documents with linear text flow. It does not perform layout analysis, so multi-column documents will produce interleaved text. It does not extract table structure, so tables will appear as jumbled text with cell contents running together. It does not handle scanned documents (image-only PDFs) at all, producing empty output for pages that contain only raster images.

pdfplumber provides more control by exposing the position of every character, line, and rectangle on the page. You can use these positions to implement basic layout analysis: group characters into lines based on vertical position, group lines into paragraphs based on indentation, and detect table boundaries based on drawn lines and character alignment. This is more work than using PyPDF2 but produces significantly better output for documents with tables and columns. pdfplumber also provides a built-in table extraction method that works well when tables have visible border lines.

pdfminer.six offers the most flexible low-level access to PDF content but requires more code to produce usable output. It extracts text with positional metadata, font information, and Unicode character mappings, which enables sophisticated custom parsers. For most teams, the effort required to build a custom parser on top of pdfminer is not justified unless you have very specific extraction requirements that no higher-level tool meets.

For Word documents, python-docx extracts paragraphs, headings, lists, and tables as typed elements, which is exactly what an ingestion pipeline needs. The main limitation is that it does not handle complex formatting (text boxes, floating images with text wrapping, revision tracking) as reliably as the simple paragraph-and-table case.

Layout Aware Parsing

Layout aware parsers analyze the visual structure of a document page before extracting text. They detect regions (text blocks, tables, figures, headers, footers), determine reading order, classify each region by type, and extract text in the correct sequence with structural annotations. This produces dramatically better output for complex documents compared to simple text extraction.

Unstructured.io is the most widely adopted open-source solution. It combines rule-based heuristics with machine learning models to detect document layout, classify elements (Title, NarrativeText, Table, ListItem, Header, Footer), and extract text in reading order. It handles PDFs, DOCX, PPTX, HTML, images, and many other formats through a unified API. The output includes element types and hierarchy, which enables section-aware chunking strategies that respect document structure. Unstructured.io is available as a Python package, a self-hosted API, and a managed cloud service.

Docling (open source, from IBM Research) uses a deep learning model trained on document images to detect layout structure. It performs particularly well on research papers, technical reports, and documents with complex multi-column layouts. Docling outputs structured JSON with element types, hierarchy, and page positions, and includes a dedicated table extraction model that handles tables with merged cells, spanning headers, and implicit borders.

LlamaParse (from LlamaIndex) is a cloud-based parsing service that uses LLMs to understand document structure. By leveraging a language model's understanding of document semantics (not just visual layout), it can extract structured text from documents that defeat purely visual approaches, such as forms with complex field layouts or documents where the structure is conveyed through formatting rather than spatial arrangement. It is available as an API with a free tier for experimentation.

Amazon Textract is a cloud service that combines OCR with layout analysis. It detects text, tables, forms (key-value pairs), and signatures in both digital and scanned documents. It is the strongest option for organizations already on AWS infrastructure and for documents that mix printed text with handwritten annotations. Pricing is per page, which makes it cost-effective for moderate volumes but expensive at scale.

The choice between these tools depends on your document types, volume, infrastructure, and budget. For general-purpose document parsing with good quality and no cloud dependency, Unstructured.io is the standard recommendation. For research papers and technical documents, Docling's deep learning approach often produces better results. For scanned documents and forms, Amazon Textract is the most reliable. For complex documents where visual layout analysis falls short, LlamaParse's LLM-based approach fills the gap.

OCR for Scanned Documents

Scanned documents, images of paper pages saved as PDF or image files, contain no extractable text. The content exists only as pixel patterns that must be interpreted by optical character recognition (OCR) before the text can be used in an AI pipeline.

Tesseract is the standard open-source OCR engine, maintained by Google. It supports over 100 languages and produces reasonable accuracy on clean, high-resolution scans of printed text. The typical accuracy on a clear 300 DPI scan of a standard business document is 95% to 99% at the character level, which sounds high but means 5 to 50 errors per page, enough to garble key facts, names, and numbers. Tesseract works best when the input image is preprocessed to enhance contrast, remove noise, correct skew, and segment the page into text regions before OCR is applied.

Cloud OCR services (Google Cloud Vision, Amazon Textract, Azure AI Document Intelligence) typically produce higher accuracy than Tesseract, particularly on challenging inputs like low-resolution scans, photographed documents, mixed-language text, and handwritten content. The accuracy improvement comes from larger and more diverse training data, multi-scale analysis, and language models that provide contextual correction. The trade-off is cost and latency: cloud OCR adds network round-trip time and charges per page or per character.

For AI applications, OCR accuracy is especially important because OCR errors propagate through the entire pipeline. A misrecognized digit in a financial table, a garbled proper noun in a legal contract, or a dropped word in a medical record will produce embedding vectors that point in the wrong direction, retrieval results that miss the relevant document, and generated answers that cite incorrect information. When ingesting scanned documents, it is worth running OCR quality checks (spell-check the output, compare character distribution against expected patterns, sample and manually verify a subset of pages) before accepting the output into the knowledge base.

Table Extraction

Tables contain dense, structured information that is critical for many AI applications, pricing tables, comparison matrices, financial statements, specification sheets, and regulatory data all live in tables. Extracting tables accurately is one of the hardest problems in document parsing because table structure is usually implied by visual alignment rather than explicitly encoded.

The simplest case is tables with visible borders, drawn lines that define every cell boundary. pdfplumber and Camelot detect these lines and use them to segment the text into rows and columns with high accuracy. The output is a grid of cells that can be converted to CSV, JSON, or textualized into natural language descriptions.

The harder case is borderless tables, where the structure is implied by the spacing and alignment of text. These tables are common in financial reports, academic papers, and government documents. Extracting them requires inferring column boundaries from horizontal text alignment and row boundaries from vertical spacing, which is ambiguous when columns have variable widths or cells contain multi-line text. Layout-aware parsers like Docling and Amazon Textract include dedicated table models trained on large datasets of both bordered and borderless tables, and they handle this case significantly better than simple heuristic approaches.

For AI applications, the question of how to represent extracted tables matters as much as the accuracy of extraction. The raw grid format (a matrix of cell values) is not ideal for LLM consumption because the model needs to understand which cells are headers, what the relationships between columns mean, and how to interpret the values in context. Converting each table row into a natural language statement ("In Q3 2025, product revenue for North America was $4.2M, representing 23% of total revenue") produces representations that embed and retrieve better than raw tabular data. The tradeoff is that textualization is lossy, it adds interpretation that may be wrong, and verbose, it uses more tokens. For tables where exact values matter (financial data, specifications), preserving the structured format alongside a textualized summary gives the LLM both options.

Choosing the Right Approach

The parsing approach should match the documents you are actually processing, not the hardest case you might theoretically encounter. Many teams over-invest in sophisticated parsing infrastructure when their corpus consists of well-structured Markdown and HTML files that simple extraction handles perfectly.

Use simple extraction (PyPDF2, python-docx) when your documents are single-column, text-heavy, and well-formatted. Common examples: policy documents, articles, reports, manuals with linear text flow.

Use layout-aware parsing (Unstructured.io, Docling) when your documents contain tables, multi-column layouts, complex formatting, or a mix of element types. Common examples: research papers, annual reports, product specification sheets, regulatory filings.

Use OCR (Tesseract, cloud services) when your documents are scanned images rather than digital text. Common examples: archived records, signed contracts, handwritten notes, photographed whiteboards.

Use LLM-based parsing (LlamaParse) when your documents have unusual layouts that defeat visual analysis or when the semantic structure is more important than the visual structure. Common examples: complex forms, non-standard layouts, documents where the meaning depends on understanding the content rather than its position.

In most production pipelines, you will use multiple approaches for different document types. The connector pattern described in the pipeline building guide handles this naturally: the file connector detects the document type and dispatches to the appropriate parser, while the rest of the pipeline processes the output identically regardless of which parser produced it.