How Does PDF Parsing Actually 'Read' a PDF?

A primer for developers - plus a look at what ComPDF AI is doing on this path

If you search for 'PDF parsing' or 'PDF parser', you'll usually see a long list of tool names and a line of marketing copy. But once you plug these tools into RAG, contract review, or document structuring workflows, you realize how much engineering sits behind those four words. This article explains the fundamentals from the ground up, and ends with a quick look at an open-source solution we've built.

I. A Real-World Scenario
Last week I helped a friend who is building a legal RAG system debug an issue. They used a commercial PDF parsing SaaS and fed 1,000 contracts into an LLM. When the model answered customer questions, it cited:
"According to the content you provided, paragraph 3 on page 8 says..."
The user clicked through and found it was nowhere near that passage.
After half a day of debugging, the conclusion was painful: in this setup, so-called 'PDF parsing' only did half the job. The SaaS extracted all text from the PDF and reshuffled it, but dropped the original coordinate information entirely. The model could only guess where the quote came from by semantics, and no one noticed when it guessed wrong.
This is not an isolated case. If you search GitHub, Reddit, or Zhihu, you'll find that almost everyone who has done document extraction or RAG has run into similar problems:
The tables fall apart after parsing; columns no longer line up;
OCR works on the scan, but the page numbers cited by the LLM don't match the actual location;
There are handwritten edits on clause 8 of the contract, but the parsed result doesn't reflect them at all;
You want to highlight the original text on the frontend, but you don't have coordinates.
All of these issues point to the core challenge in PDF parsing: how to turn a page that was 'drawn' into structured, searchable text with coordinates. Let's unpack that step by step.

II. What Is PDF Parsing
PDF (Portable Document Format), at its core, is a 'page description language'. It records not what a document is, but what each page looked like at a certain moment and position. The internal structure of a PDF is roughly:
Header: the PDF version.
Body: a collection of objects - text objects, font objects, image objects, and graphic objects.
Cross-reference table (Xref): the index of offsets for all objects.
Trailer: marks the end of the file and tells the reader which object to start from.
In other words, a PDF is 'drawn', not written in the natural order of paragraphs, sentences, and characters. So the core job of PDF parsing is to reverse that drawing into a structured, readable, searchable text stream while preserving semantic and positional information as much as possible.
That sounds simple; it is not. That's exactly why this field has so many tools and so many diverging technical approaches.

III. Why PDF Parsing Is So Hard
For developers, the pain of PDF parsing comes mainly from four sources. Understanding them is the only way to understand why we need three different approaches later on.

1. Layout Complexity Two-column pages, tables spanning pages, footnotes, headers and footers, embedded charts - to restore the natural reading order, you need layout analysis.
2. Mixed Content A PDF may contain digital text, raster images, scanned pages, vector graphics, and handwritten annotations all at once. Content from different sources needs different processing paths.
3. Fonts and Encoding Embedded font subsets, custom CMaps, and even private ToUnicode tables can all cause broken text if handled incorrectly, or make the same character appear as several completely different ones.
4. Risk of Losing Coordinates Many PDF parsing tools output only a plain text stream and quietly drop coordinate information. The result: model errors go unnoticed, the frontend cannot do highlighting, and you cannot use the output for multimodal SFT training.

IV. Three Mainstream PDF Parsing Approaches
Today, PDF parsing in industry is broadly done in three ways. Using a PDF that contains text, tables, and scanned pages as an example, let's walk through what each approach does, how it works, and what it costs.

Approach 1: Native PDF Stream Extraction (Text Stream Extraction)
Principle: The PDF content stream directly records each text object's position (x, y), font, and font size. The parser reads these objects and sorts them by coordinates to obtain character-level text and coordinates.
How it works: Use a PDF interpreter (PDFium, Poppler, qpdf) to decode the content stream; translate operators (BT/ET, Tj, TJ, cm) into text fragments with coordinates; run layout analysis if needed (rule-based or ML) to reconstruct reading order.
Pros: Extremely fast (seconds), runs on CPU only; character-level coordinates with almost no jitter; low memory usage.
Cons: Completely ineffective on scanned or image-only PDFs (there are no text objects in the content stream); two-column and cross-page tables require extra layout reconstruction.
Representative tools: pdfplumber, PyMuPDF (fitz), Apache PDFBox.

Approach 2: Two-Stage OCR + Layout Analysis
Principle: First rasterize the PDF page into an image (300 DPI), then use a text-detection model to locate text regions, run OCR on each region, and finally pair the recognized text with coordinates in the output.
How it works: Render PDF pages to PNG/JPG; use text detection (DBNet, CTPN, CRAFT) to find bounding boxes; OCR engines (PaddleOCR, Tesseract, Surya) read the text; layout analysis (Layout-Parser, DocLayNet) reconstruct paragraphs, tables, and figures.
Pros: Treats born-digital and scanned PDFs the same way; with layout analysis models it can handle complex formats.
Cons: Coordinate jitter - detection boxes and recognition boxes often do not align; slow - a 100-page document can take minutes; strong GPU dependence - without a GPU, it's basically unusable.
Representative tools: PaddleOCR, Surya OCR + Layout-Parser, Tesseract + custom post-processing.

Approach 3: End-to-End Multimodal Models (VLM-Based)
Principle: Use a vision model directly: input one rendered PDF page image and output Markdown / JSON / HTML with coordinates. Recognition, layout, and reconstruction happen in a single inference pass.
How it works: Render the PDF page image; feed it to a VLM (GPT-4o, Qwen2-VL, InternVL, or doc-focused smaller models such as Nougat); the model directly emits structured results, with bboxes embedded in the output.
Pros: One-stop processing for complex layouts, formulas, charts, and scanned pages; accurate bboxes, because the model 'looks at the image' while generating the output, avoiding a mismatch between detection boxes and recognition boxes.
Cons: Slowest by far, with large memory usage; large models raise the bar for local deployment; weak support for long documents, which get truncated once they exceed the context window.
Representative tools: GPT-4o document parsing, Qwen2-VL, InternVL, Nougat, Marker.

A Comparison Table: Which Approach Fits Your Business?
Table 1 Comparison of the three PDF parsing approaches across seven key dimensions
This table is enough for a quick decision: if you handle pure digital PDFs and care most about speed plus coordinates, approach 1 is best; if your PDFs are mostly scans or images, approach 2 or 3 is required; if the layout is complex (two columns, tables, formulas mixed together), the end-to-end idea in approach 3 is the least painful - but at the cost of memory and long-document support.

V. A Counterintuitive Conclusion
After several months of internal evaluation, we reached a counterintuitive conclusion: the PDF parsing solution that really works is not to choose one of the three, but to combine them adaptively.
Concretely, it is a decision chain:
For each PDF page, first determine whether it is a 'digital' PDF - that is, whether the content stream contains text objects that can be parsed.
If it is digital -> use approach 1 and get character-level coordinates in seconds.
If it is a scanned page -> use approach 2 or 3, choosing adaptively based on layout complexity and budget.
If it is a complex layout (multi-column, tables, formulas mixed together) -> go directly with approach 3.
This hybrid parsing pipeline is the only approach that really runs in production. The idea behind it is simple: put the right algorithm in the right place.

VI. So We Built a New Solution: DocSlight
Based on the idea above, we built an open-source document parsing and data extraction engine - DocSlight. It packages the 'decision + adaptive scheduling' pipeline so you don't have to stitch together three tools yourself.

Three Differentiators

Dual Mode (local + cloud): the local mode is free, offline, and CPU-runnable, with all data staying on your own server; the cloud mode is based on VLMs and delivers higher accuracy. It scores 96.45 on OmniDocBench overall, outperforming models such as MinerU2.5-Pro, GLM-OCR, and PaddleOCR-VL. This addresses the data-compliance concerns and the 'high barrier to local deployment' pain point most relevant to finance, legal, and healthcare customers.

Bbox-level coordinate traceability: structured field extraction includes precise bbox coordinates, with Markdown / JSON / plain text outputs. This directly addresses the coordinate-loss risk in section three - the frontend can highlight text, and models can trace sources, because accurate positions are available. It is also the answer to the pain point of wanting to highlight original text but not having coordinates.

Multi-format + 80+ language OCR: PDF / scanned documents / images / Office files (Word, PPT, Excel) are handled in a unified way, and OCR supports 80+ languages with automatic detection. As with the issues in section one, such as page citation mismatches on scans and handwritten edits not showing up in contracts, complex layouts and scanned pages can both be processed reliably.

These three differentiators correspond to the real-world pitfalls listed at the beginning of the article. There is also a related project, ComPDF Self-Hosted, a Docker one-click PDF editing/conversion platform that can be combined with DocSlight into a complete document pipeline. We ultimately chose to open-source DocSlight because we want the Chinese developer community to have a more convenient implementation path.

VII. A Question for You
If you've worked on PDF parsing:
"What was the most ridiculous bug you ever encountered while doing PDF parsing?"