PDF Data Extraction Tools, a Buyer Checklist

The four kinds of tools you will meet

Before scoring anything, it helps to know which category each candidate belongs to. The categories have different strengths, and comparing across them without knowing that leads to unfair tests.

Open source libraries run inside your own process. Some read the text layer of digital PDFs with positions, some detect tables, some wrap an OCR engine for scans. They cost nothing per page and keep data on your machines. You own the integration, the edge cases, the scaling and the upgrades. Quality on tables and scans varies a lot between libraries and between document types.

Cloud OCR suites are large platform services that turn images and PDFs into text, lines and sometimes key value pairs and tables. They are strong on raw recognition and scale. Output is usually close to the page geometry, so you still write code to turn it into business records, and pricing often differs per feature, per page type or per model.

No code template tools let operations staff draw zones or rules on a sample document and reuse them for documents with the same layout. They work well for a small number of stable templates and poorly when every supplier sends a different layout. They are usually built around a web interface rather than an API.

API first parsers accept a document over HTTP and return structured output designed for code: a layout tree, Markdown, tables as CSV, fields from a schema you define, and often chunks for retrieval. You trade per page fees for not maintaining the extraction layer. The differences between them are in output quality on hard pages, schema support, limits, data handling and price model.

PdfParse is in the last category. It is fair to say so up front, and the checklist below is written so you can apply it to every category, including ours.

The buyer checklist

Work through these questions with your own documents in hand. Every answer should come from a test or from written documentation, not from a sales conversation.

Output formats

Ask what the tool returns and whether you get it in one call. A pipeline that needs JSON for the application, Markdown for a language model and CSV for an analyst should not have to parse the same document three times.

Is there a layout output with block types, reading order and bounding boxes
Is Markdown available and does it keep headings, lists and tables
Can tables be exported as CSV directly
Are coordinates and page numbers kept so results can be traced back to the page

Tables

Tables decide most evaluations. Test the hard cases on purpose.

Merged header cells spanning several columns
Tables that continue across a page break with a repeated or missing header
Borderless tables where columns are implied by alignment
Nested headers and subtotal rows
Numbers with currency symbols, thousands separators and negative values in parentheses

Our pdf table extraction page shows the table output format so you can compare like for like.

Scans and images

Many real pipelines receive phone photos, faxes and scanned contracts. Check whether the tool detects pages without a text layer and runs OCR automatically, whether it handles skewed and low contrast scans, whether mixed documents (some pages digital, some scanned) work in one request, and which image formats are accepted, such as PNG, JPG and multi page TIFF.

Schemas and typed fields

If you need business records rather than text, schema support is the deciding feature.

Can you define fields, types and descriptions yourself
Are money and dates returned in a normalised form
Does each field carry a confidence value and the page it came from
Are missing values returned as null rather than guessed
Can schemas be versioned and reused across thousands of documents

The pdf data extraction page shows how schema extraction works in both the API and the web app.

Security and retention

Documents are often the most sensitive data a company holds. Read the data handling terms, not the marketing page.

Encryption in transit and at rest
How long files and results are kept, and whether you control that
Whether a zero retention mode exists
Whether your files are used to train models
Audit logs, single sign on, roles and processing region
Whether a data processing agreement is available

Ask for written answers. A vendor that will not state its retention period in writing is giving you an answer.

Predictable price per page

Per page pricing is easy to model only when a page means the same thing everywhere. Check what counts as a page, whether tables, OCR or schema extraction cost extra per page, what happens at the plan limit, and whether overage is charged automatically. A predictable model is one where you can compute next month's maximum bill from your plan alone.

SDKs, webhooks, batch and limits

Official SDKs for the languages your team uses, with typed responses
Webhooks with signed payloads and retries, so you do not poll
Batch submission with an idempotency key so retries do not duplicate jobs
Maximum file size and maximum pages per file on each plan
Rate limits and how the API signals them

Lock in

Ask how hard it would be to leave in a year. Output in open formats (JSON, Markdown, CSV) is easy to move. Proprietary template files, visual rules or schemas stored only in a vendor interface are not. Keep your schemas in your own repository and your validation in your own code, whichever tool you choose.

A scoring table to fill in

Weight each criterion by how much it matters to your project, score every candidate from 1 to 5 based on your own tests, and multiply. The weights below are a starting point for a team building a product feature on top of document extraction. Change them to match your situation.

Criterion	Weight	What a 5 looks like
Table quality on your hardest documents	5	Merged cells and multi page tables come back correct and complete
Schema extraction with typed fields	4	Your schema, normalised money and dates, confidence and source page per field
Scans and mixed documents	4	OCR runs automatically, mixed documents work in one request
Output formats in one call	3	JSON, Markdown and CSV from the same request
Security and retention	4	Written retention terms, zero retention option, no training on your files
Predictable price per page	3	Monthly maximum cost known from the plan, no automatic overage
SDKs, webhooks and batch	3	Typed SDKs, signed webhooks, idempotent batches
Limits that fit your files	2	File size and page count limits above your largest real document
Low lock in	2	Open output formats, schemas you keep in your own repository

Score with your documents, not the vendor's samples. Collect thirty to fifty files that represent your real traffic, including the ugly ones, and run every candidate on the same set. Record failures by type so the scores are explainable.

A small test harness

Keep the evaluation reproducible. Store the files, the expected values for a handful of fields per document and a script that runs each candidate and compares. Here is the PdfParse side of such a harness in Python. The other candidates get the same function signature.

Python

import json
import os
from pathlib import Path

from pdfparse_ai import PdfParse

client = PdfParse(api_key=os.environ["PDFPARSE_API_KEY"])


def run_pdfparse(path: Path) -> dict:
    result = client.parse(str(path), outputs=["json", "csv"], schema_id="invoice_v3")
    return {name: f["value"] for name, f in result["fields"].items()}


def compare(expected: dict, actual: dict) -> list[str]:
    misses = []
    for field, want in expected.items():
        got = actual.get(field)
        if got != want:
            misses.append(f"{field}: expected {want}, got {got}")
    return misses


report = {}
for pdf in sorted(Path("eval/docs").glob("*.pdf")):
    expected = json.loads(pdf.with_suffix(".json").read_text())
    report[pdf.name] = compare(expected, run_pdfparse(pdf))

print(json.dumps(report, indent=2))

The same check in Node takes a few lines with the SDK.

TypeScript

import { PdfParse } from "pdfparse-ai";

const client = new PdfParse({ apiKey: process.env.PDFPARSE_API_KEY });
const result = await client.parse({ file: "eval/docs/invoice-017.pdf", outputs: ["json", "csv"] });
console.log(result.tables.length, result.usage.pages);

Build against buy, counted in engineering hours

The honest comparison is not license cost against zero. It is the engineering time to reach and keep the quality you need against the subscription. Every team's numbers differ, so instead of quoting figures, here is the list of work to estimate with your own team.

Building on open source libraries means owning these pieces of work.

Choosing and integrating a text layer reader, a table detector and an OCR engine, and reconciling their different coordinate systems
Reading order for multi column pages, header and footer removal, and heading detection
Table reconstruction for merged cells and tables across page breaks
Field extraction for every document family, with typing for money and dates
A queue, workers, retries, timeouts and scaling for large files and spikes
Storage, encryption and deletion that match your retention policy
Monitoring, error triage and a review interface for low confidence results
Ongoing maintenance as library versions change and new document layouts arrive

Buying means owning a smaller list: the integration, schemas, validation in your own code, the review step and the vendor relationship.

To compare, estimate hours for each item, multiply by a loaded hourly cost and add the ongoing maintenance per month. Then compare that with the plan that covers your page volume. For reference, PdfParse plans start at $49 per month or $24 per month billed yearly for 2,000 pages, Growth is $149 a month, or $74 a month billed yearly ($888 a year), for 7,000 pages, Scale is $499 a month, or $249 a month billed yearly ($2,988 a year), for 24,000 pages, and Enterprise is $1,499 a month, or $749 a month billed yearly ($8,988 a year), for 72,000 pages. All plans are on the pricing page.

Building can be the right call. If your documents are a single stable layout, your volume is very large, your data cannot leave your network under any terms, or document understanding is the core of your product, owning the stack may pay off. If documents are one input among many and your team's time is better spent on the product, buying usually wins. Whichever path you take, keep schemas and validation in your own code so the decision stays reversible.

Red flags during evaluation

Accuracy claims without a description of the test set
Retention terms that are vague or only available on request
Pricing where table, OCR or field extraction is billed separately per page and the total is hard to predict
Automatic overage charges with no cap
Templates or schemas that can only be edited inside a vendor interface
No way to trace an extracted value back to its page

A short decision path

Know the category of each candidate. Test on your own documents, especially tables and scans. Score with weights that reflect your project. Read the retention terms and the pricing rules in writing. Count build costs in your own engineering hours. Keep schemas and validation in your repository so you can switch later.

If PdfParse is on your list, the API documentation describes every option, the security page states retention per plan, and the pdf to json page shows a full response.

PDF data extraction tools, a checklist for engineering leads