DEV Community: Felipe Cardona

The 8 Best Google Document AI Alternatives in 2026

Felipe Cardona — Wed, 14 Oct 2026 14:07:37 +0000

The best Google Document AI alternatives in 2026 are anyformat, AWS Textract, Azure Document Intelligence, ABBYY, Nanonets, Reducto, LlamaParse, and Unstructured. Teams switch for four main reasons: European data sovereignty, on-premise deployment, the 15-page cap on online processing, and the operations layer (classification, routing, validation, human review, accuracy monitoring) that Google's extraction API leaves engineers to build and maintain.

We compared each tool on five criteria: zero-shot custom field extraction, on-premise deployment, EU data sovereignty, pricing model, and workflow orchestration. Facts come from vendor documentation, published pricing, and a benchmark run on 1,000+ real documents. Last evaluated: October 2026.

Comparison table

Tool	Best for	Zero-shot custom fields	On-premise	EU sovereignty	Pricing model
anyformat	Custom schemas on complex documents, with accuracy you can measure	Yes	Yes, incl. air-gapped	EU-native, ISO 27001	Per page, per operator ($25/1,000 pages parsing)
AWS Textract	Forms and tables in AWS stacks	No (Queries: English only)	No	US jurisdiction	Per page ($65/1,000 for forms + tables)
Azure Document Intelligence	Microsoft-stack teams	No (5+ labeled docs)	Partial (containers)	US jurisdiction	Per page ($10/1,000 prebuilt, $30 custom)
ABBYY	Traditional enterprise IDP	No (Skills + training)	Yes (FlexiCapture)	US-headquartered	License + professional services
Nanonets	Mid-market no-code automation	Partial (HITL annotation)	Enterprise contract only	US multi-tenant	Per block run ($0.02–$0.30)
Reducto	Engineering teams wanting a parsing API	Yes (API schemas)	Yes (VPC, air-gapped)	US company, EU endpoints	Usage-based API ($10 parse, $20 extract per 1,000)
LlamaParse	Parsing documents into LLM-ready Markdown	Partial (parsing-first)	Enterprise self-hosted	US cloud API	Credit-based per page ($1.25–$56.25/1,000)
Unstructured	RAG preprocessing with connectors	No (elements, not fields)	Yes (self-hosted)	US company	Apache-2.0 library; platform $0.015/page after 10,000 free

1. anyformat

anyformat is an agentic document intelligence platform built in the EU, and the strongest fit when the reason you are leaving Google Document AI is sovereignty, deployment, or the operations and measurement layer around extraction. It extracts any user-defined schema zero-shot, with no labeled samples or retraining cycles, and links every extracted value to its exact position on the page through visual citations. It deploys on-premise, including air-gapped environments, is ISO 27001 certified, and offers zero data retention as an Enterprise option. In its published July 2026 benchmark on 1,000+ real documents, anyformat scored 78.1% on parsing quality versus 55.0% for Google Document AI, and held roughly 99% row recovery on 50-page tables.

Two things separate it from the raw-API options in this list. Classification, routing and human review are configured in a visual Studio instead of being assembled from cloud functions, queues and a review UI your team writes and maintains. And every Extract and Classify workflow ships a Health tab for evaluation: build a dataset with verified ground truth (promoted from reviewed production files or uploaded as labelled data), tag sub-datasets to slice accuracy by provider, document type or difficulty, and run numbered, immutable evaluations that score any workflow version field by field against that ground truth, with result-versus-expected comparisons. The Health Overview puts the dataset benchmark next to live production accuracy, confidence and through rate. anyformat has also announced Optimizer, a workflow that tunes itself against its own dataset using your evals as the target; it is not shipped yet.

Pricing is credit-based, charged per page and per operator (10 credits = €0.01): Parse 25 credits per page, Extract 35, Classify 10, Split 25, with agentic variants at 100 and 150. The $25 per 1,000 pages in the benchmark is the parsing rate.

Best for: Custom schemas on complex documents, with accuracy you can measure.

2. AWS Textract

AWS Textract is Amazon's OCR service, launched in 2019, and the natural pick for engineering teams already running on AWS. It extracts text, forms, tables, and signatures from PDFs and images, with table detection that ranks among the strongest of the cloud providers, and integrates directly with S3, Lambda, SNS, and SQS. It returns raw OCR output rather than schema-shaped data, so field mapping, validation, and orchestration are custom engineering work. AWS's published pricing is $65 per 1,000 pages for the combined forms and tables analysis, rising to $70 when queries are added. Textract is cloud-only on AWS and governed under US jurisdiction regardless of region selection.

Best for: AWS-native engineering teams extracting structured forms and tables who can build their own pipeline.

3. Azure Document Intelligence

Azure Document Intelligence, formerly Form Recognizer (renamed in 2023), is Microsoft's document processing service and the path of least resistance for organizations deep in the Azure ecosystem. Its pretrained models cover invoices, receipts, IDs, and tax forms, and it handles multi-column tables and nested structures better than most cloud rivals; independent benchmarks have reported around 96% accuracy on printed text. Custom fields require labeling documents in Document Studio, five examples minimum per Microsoft's documentation and usually more, plus a training cycle, and schema changes mean relabeling. Container deployment is genuinely partial: the current v4.0 GA API ships containers for Read and Layout only, and custom extraction models have no container path; the full platform is cloud-only under US jurisdiction. Prebuilt models cost $10 per 1,000 pages (invoices, receipts, IDs and others), custom extraction $30 and Read $1.50 (Azure pricing page, read October 2026).

Best for: Microsoft-stack teams whose documents match a pretrained model.

4. ABBYY

ABBYY is the longest-standing vendor in this list, founded in 1989 and now headquartered in Austin, Texas, with two products: Vantage (cloud IDP) and FlexiCapture (on-premise capture). Its 150+ pre-built extraction Skills and two decades of enterprise deployments translate into genuinely strong accuracy on supported document types, including handwriting. The trade-off is the delivery model: implementations typically run weeks to months with third-party integrators, professional services budgets range from $15K to over $200K, and contracts commonly require 3-year terms with annual prepayment. FlexiCapture remains one of the few mature, fully on-premise options in the market.

Best for: Large enterprises with stable document portfolios and the budget for a traditional IDP deployment.

5. Nanonets

Nanonets is a mid-market document automation platform, founded in 2017, whose block-based no-code workflow builder is its clearest differentiator: import, data-action, and export blocks with conditional logic that non-technical users can assemble. Extraction is template-free, though Nanonets' own documentation notes that non-standard documents may need human-in-the-loop annotation before reaching production accuracy. Pricing is per block run, between $0.02 and $0.30 depending on complexity, and Nanonets' own pricing page puts a typical invoice workflow at four to six block runs per document, so the per-run figure is not the per-document cost. Data sits on US multi-tenant infrastructure by default, with retention of roughly 30 days after termination; on-premise deployment is available only via enterprise contract.

Best for: Mid-market teams automating standard document types without engineering involvement.

6. Reducto

Reducto is a US document parsing API, founded around 2023, that has raised $108M in total, including a $75M Series B led by a16z in October 2025 (Reducto announcement). Pricing is usage-based: Parse r-1 is $10 per 1,000 pages flat and Extract is $20 per 1,000 pages (Reducto pricing, September 2026). Its agentic OCR combines multi-pass vision-language models with error correction, and it publishes an open table-extraction benchmark, RD-TableBench, which is more transparency than most vendors offer. Extraction is schema-driven and zero-shot through the API, but there is no UI: every schema change goes through a developer, and classification, routing, human review and accuracy monitoring are yours to build around the Parse, Split, Extract, and Edit endpoints. Deployment spans cloud, VPC, and air-gapped on-premise. It holds SOC 2 Type II and offers HIPAA processing with a BAA on higher tiers; ISO 27001 is not listed.

Best for: Engineering teams that want a high-accuracy parsing primitive and will build the platform around it.

7. LlamaParse

LlamaParse is LlamaIndex's document parsing API, launched in February 2024, purpose-built to convert documents into LLM-ready Markdown for retrieval-augmented generation. Its speed is real: an independent Procycons benchmark measured about 6 seconds for both 1-page and 50-page documents in batch mode. The constraint is the output format. Markdown flattens merged cells, row spans, and nested table relationships, which limits downstream structured extraction, and while confidence scores are documented on its upper tiers, the calibration is self-reported and has no published evaluation, and there is no review interface in the product. It holds SOC 2 Type 2; ISO 27001 is not listed, and the standard offering is a US cloud API with enterprise self-hosting via Kubernetes. Pricing is credit-based: parsing runs from $1.25 (Fast) to $56.25 (Agentic Plus) per 1,000 pages, plus 10 credits per page containing a form (LlamaParse pricing, September 2026).

Best for: Fast, cost-effective RAG ingestion inside the LlamaIndex ecosystem.

8. Unstructured

Unstructured is a partially open-source preprocessing platform that converts documents into element arrays (text blocks, tables, images) for LLM pipelines, with the widest connector ecosystem in the category: 40+ connectors including Databricks, Elasticsearch, S3, and Google Drive. Its commercial platform holds SOC 2 Type II, ISO 27001, and HIPAA certifications, plus FedRAMP High authorization (announced December 2025) (the open-source library is not in scope), and self-hosted deployment gives full data control. What it deliberately does not do is field-level structured extraction: you get chunks for retrieval, not schema-defined values for an ERP or database. Teams that need both often pair it with an extraction platform rather than replacing one with the other.

Best for: AI teams building RAG pipelines that need broad connector coverage rather than field extraction.

How to choose

Data sovereignty. If GDPR, DORA, or sector rules govern your data, distinguish between EU regions on a US-governed platform and EU-native governance. Google Document AI remains US-governed regardless of region selection.
Custom schemas. Google's Custom Extractor now runs on a foundation model that extracts from a schema alone, with no labeled documents; few-shot accepts up to 5 examples and fine-tuning needs 50 training plus 50 test documents to reach production accuracy. If schema flexibility is your only complaint, Google may already solve it. anyformat and Reducto are the other zero-shot options; ABBYY, Azure and Nanonets still involve labeling.
The pipeline around the API. A raw OCR API returns text and blocks. Post-processing, schema validation, retry and routing logic, a review UI, accuracy monitoring and re-tuning after every layout or model change are yours to build and keep running. Price that engineering alongside the per-page rate, because it is usually the larger number.
How you will measure accuracy. Per-field confidence is a starting point; a dataset with verified ground truth and repeatable, versioned evaluations is what lets you change a workflow without guessing. Google offers evaluation in Workbench for custom processors, anyformat ships it as the Health tab on every Extract and Classify workflow, and the parsing APIs leave it to you.
Pricing shape. Per-page, per-operator and per-run models compound differently; model your real monthly volume, including reprocessing and multi-step workflows, before comparing list prices.
Deployment. Cloud-only rules out many regulated environments. On-premise options in this list: anyformat, ABBYY FlexiCapture, Reducto, and self-hosted Unstructured.
Scope. Decide whether you need a parsing API you build around (Reducto, LlamaParse) or an operations platform with workflows, review, and orchestration included (anyformat, Nanonets).

Frequently asked questions

Is Google Document AI free?
No. Google Document AI is pay-per-use on Google Cloud. Enterprise Document OCR is $1.50 per 1,000 pages up to 5 million; Form Parser and Custom Extractor are $30 per 1,000 pages, falling to $20 above a million; Layout Parser is $10 per 1,000; and the pretrained invoice parser bills $0.10 per document of up to 10 pages (Google Cloud pricing, read October 2026). There is no free tier for production volumes.

What is the best Google Document AI alternative for EU companies?
anyformat is the strongest fit for EU companies: it is EU-native, ISO 27001 certified, GDPR-compliant by architecture, and deploys on-premise including air-gapped environments with zero-retention processing. ABBYY FlexiCapture also keeps data on your own infrastructure, though with a traditional implementation model measured in weeks to months.

Can I extract custom fields without training data?
Yes, and Google itself can do this now. Its Custom Extractor runs on a foundation model that extracts user-defined fields from a schema alone; few-shot prompting accepts up to 5 labeled examples, and fine-tuning requires at least 50 training and 50 test documents to reach production accuracy (Google Cloud documentation, 2026). anyformat and Reducto are also zero-shot from a schema definition. Azure Document Intelligence still requires at least 5 labeled documents plus a training cycle in Document Studio.

Which Google Document AI alternatives support on-premise deployment?
anyformat (including air-gapped environments), ABBYY FlexiCapture, Reducto (VPC and air-gapped), and Unstructured (self-hosted) all run on your own infrastructure. Google Document AI is cloud-only on GCP, Nanonets offers on-premise only through enterprise contracts, and Azure's containers cover a subset of features.

If Google Document AI is the specific tool you are replacing, the head-to-head comparison goes deeper: anyformat vs Google Document AI covers zero-shot extraction, the 15-page online processing limit, European sovereignty, and workflow orchestration in detail.

Originally published at anyformat.ai/blog/best-google-document-ai-alternatives.

OCR for poor-quality scanned PDFs

Felipe Cardona — Wed, 14 Oct 2026 13:14:49 +0000

You need data out of a 200-page PDF because you want to feed a RAG pipeline, fill a database from contracts or filings, or ask questions that cross hundreds of pages.

If you tried putting the whole file into an LLM, we get it: the output was not good. Rows were missing, a total did not match, the answer was confident and wrong. That is not your prompt. These models were built to predict the next piece of text inside a limited window, not to read a long, structured document page by page and hand it back complete. Last evaluated: October 2026.

The short answer to how to do it properly: read the document page by page, join the pieces that belong together (above all tables that run over several pages), extract the fields from the joined result against a schema, and check that the output is complete. The rest of this guide shows why the shortcuts fail and what works.

If you put it all in an LLM, we get it: the output was not good

It is the first thing almost everyone tries, and it breaks for four reasons that have nothing to do with how well you wrote the prompt:

The answer does not fit in the reply. Models accept far more input than they can write back in one response, so a long table cannot be returned in a single call, however large the input window is.
The middle of the document gets read worse. Research on long contexts (Liu et al., 2023) shows that accuracy drops for information in the middle of a long input compared with the start and the end. The table that begins on page 87 sits in that zone. Source
Cost and latency grow with the page count, and a failed attempt repeats the whole bill.
Nothing tells you what is missing. The model answers fluently whether it saw every row or not.

The story does not end there for most teams, because the next idea is the obvious one.

So you split it into chunks, and that did not work either

Cutting the PDF into pages or fixed-size chunks solves the window problem and creates new ones. A table that runs over eight pages becomes eight unrelated fragments. Column headers that repeat on every page are read as data. A field that is printed once on page 1, such as the supplier or the contract number, is invisible to the chunk that reads page 40. Soon the code that stitches results back together is bigger than the extraction itself, and it breaks with every new layout.

The more careful variants (splitting by sections, or extracting each table row in parallel) help, but each leaves something open: a table that crosses a section boundary, or document-level fields living in a different call. We go through these trade-offs in our long-documents essay.

The approaches, side by side

Approach	Keeps multi-page tables whole	Document-level fields next to table rows	Tells you if rows are missing	Typical limit
Whole document in one prompt	Only if it fits the reply	Yes	No	Output cap, middle-of-context loss, cost
Fixed-size or page chunks	No	No	No	Stitching code becomes the product
Split by sections, extract in parallel	Not across a section boundary	Needs a separate pass	No	Tables that cross a boundary
One extraction per table row, in parallel	Row by row	Separate call	Partly	Document context lives in another call
Agentic IDP (OCR + parse per page, extract across pages)	Yes, if table continuity is detected	Yes, same schema	Yes, if you add checks	Needs a parser that keeps layout and structure

The last row is the pattern that holds up, and it is what an agentic IDP does. For tools that implement these patterns, see the best document parsing APIs.

The solution: an agentic IDP with OCR

The pattern that holds up is what an intelligent document processing (IDP) platform does: OCR and layout analysis first, then an agent that reasons over the whole document. anyformat works like this, in two layers:

Parse every page on its own, in parallel. OCR and layout analysis split each page into blocks (text, tables, figures, headers, footers) and fix the reading order. Each page is independent, so 300 pages are 300 small jobs and not one huge one. Scans go through OCR first.
Extract across the whole set of parsed blocks. An agentic extractor looks at the blocks of every page, recognizes which table fragments belong to the same table and joins them in order, and reads document-level fields from wherever they sit.

You describe the result once, as a schema with two kinds of fields: values that appear once per document (supplier, contract reference, filing date, total) and a table field with its columns. A single run returns both together, so you do not need a second pass or a join afterwards. In anyformat this is a Parse node followed by an Extract node, and the Extract node has an Agentic mode intended for dense tables and values that span several pages.

The table field is an object field with nested columns:

{
  "name": "line_items",
  "description": "One row per line of the table, across all pages",
  "data_type": "object",
  "nested_fields": [
    { "name": "description", "data_type": "string", "description": "Item description" },
    { "name": "quantity", "data_type": "integer", "description": "Quantity ordered" },
    { "name": "unit_price", "data_type": "float", "description": "Price per unit" },
    { "name": "line_total", "data_type": "float", "description": "Row total amount" }
  ]
}

The result is a list with one entry per row, and every value carries a confidence score and the text and page it was read from. For the full flow with code, see how to extract structured data from a PDF with an LLM.

Try it on your own long document: the Free tier includes 50,000 credits with no credit card, enough to run a long file through this workflow.

It also works for RAG. If the goal is retrieval and not fields, the same parse step gives you the document as structured text with tables kept whole, ready to index. See PDF to markdown for LLMs.

How to check nothing is missing when you extract data from a long PDF

A long document makes silent loss easy, so build the check into the workflow:

Count the rows. If the document says "42 items", the extraction should have 42 rows. A different count flags the document.
Make the totals close. The sum of the line totals should match the printed subtotal, and subtotal plus tax should match the grand total. A validation step can run these rules on every document.
Look at the confidence of the rows that matter. Set a threshold and route what falls below it to a person who sees the source page next to the value.
Check the seams. Open the page breaks of one test document by hand: the last row of a page and the first of the next are where a table is most likely to be cut or duplicated.

Evidence on each value is what makes the manual check fast: the reviewer clicks a value and lands on the page it came from. See why grounding makes extraction auditable.

What it costs with anyformat

anyformat's pricing is credit-based, per page and per operator. At list rates, Standard Parse is 25 credits and Standard Extract 35 credits per page, so 60 credits per page; Agentic is 100 and 150 credits, so 250 credits per page. A credit costs €0.001 on Business and €0.0015 on Free and pay-as-you-go. For a 100-page document that is:

100-page document	Credits	Business (€0.001 per credit)	Free / pay-as-you-go (€0.0015)
Standard Parse + Standard Extract	6,000	€6.00	€9.00
Agentic Parse + Agentic Extract	25,000	€25.00	€37.50

Validation rules are billed separately, per rule and once per extraction rather than per page; check the credits page for the current rate. Start with Standard and move to Agentic only for the documents where Standard gets a table wrong.

Limits, stated plainly

Scans and photos lower accuracy for every method. Use a confidence threshold and a review step for them.
Agentic mode does not support multi-file documents yet (several files treated as one document). Combine files before upload or process them separately.
Very irregular tables (merged cells, tables that change columns halfway) need a test on your own files before you trust them.
Accuracy depends on your documents. Before you rely on any vendor's headline figure, ours included, test fifty of your own, count rows against the source and measure field-level accuracy.

How to choose

If your documents are short and clean, a single prompt is enough. If they are long, ask each tool three questions: does a table that spans pages come back as one table, do document-level fields come back in the same result, and what tells me a row is missing? A tool that cannot answer the third one will fail you quietly. For a comparison of vendors, see our comparisons and, for a specific one, anyformat vs Docsumo.

Frequently asked questions

Can an LLM extract data from a 200-page PDF? Yes, but not reliably in one prompt. The reply cannot hold a long table, accuracy drops in the middle of long inputs and nothing flags what was missed. Parse the pages separately and extract across them against a schema.

Why was the output of my long PDF not good? These models were built to predict text inside a limited window, not to reproduce a long structured document. They also give no signal about what they missed, so a wrong answer looks the same as a right one.

How do I extract a table that spans many pages? Detect which page-level table fragments belong together, join them in order, and ignore repeated column headers. Then compare the row count and totals with the document.

How do I get the supplier name and the line items in one result? Declare both in one schema: single fields for the document-level values and an object field with nested columns for the table. One run returns them together.

How do I know no rows were dropped? Count the rows against the document, make the totals close, and review low-confidence values with their source page open.

Can I use this for RAG? Yes: the parse step returns the document as structured text with tables kept whole, ready to index.

How much does it cost per page? At Standard rates, 60 credits per page (€0.06 on Business); at Agentic rates, 250 credits per page (€0.25 on Business).

Start with your longest documents. Upload the file that breaks your current pipeline, define the fields you need, and see the values with their confidence and their evidence on the page. The Free tier includes 50,000 credits with no credit card.

Disclosure: anyformat sells document extraction; the comparison criteria and dates are stated.

Originally published at anyformat.ai/blog/extract-data-from-long-pdfs-llm.

How to extract data from long PDFs with an LLM

Felipe Cardona — Wed, 14 Oct 2026 13:05:48 +0000

You need data out of a 200-page PDF because you want to feed a RAG pipeline, fill a database from contracts or filings, or ask questions that cross hundreds of pages.

If you put it all in an LLM, we get it: the output was not good

It is the first thing almost everyone tries, and it breaks for four reasons that have nothing to do with how well you wrote the prompt:

The answer does not fit in the reply. Models accept far more input than they can write back in one response, so a long table cannot be returned in a single call, however large the input window is.
The middle of the document gets read worse. Research on long contexts (Liu et al., 2023) shows that accuracy drops for information in the middle of a long input compared with the start and the end. The table that begins on page 87 sits in that zone. Source
Cost and latency grow with the page count, and a failed attempt repeats the whole bill.
Nothing tells you what is missing. The model answers fluently whether it saw every row or not.

The story does not end there for most teams, because the next idea is the obvious one.

So you split it into chunks, and that did not work either

The approaches, side by side

Approach	Keeps multi-page tables whole	Document-level fields next to table rows	Tells you if rows are missing	Typical limit
Whole document in one prompt	Only if it fits the reply	Yes	No	Output cap, middle-of-context loss, cost
Fixed-size or page chunks	No	No	No	Stitching code becomes the product
Split by sections, extract in parallel	Not across a section boundary	Needs a separate pass	No	Tables that cross a boundary
One extraction per table row, in parallel	Row by row	Separate call	Partly	Document context lives in another call
Agentic IDP (OCR + parse per page, extract across pages)	Yes, if table continuity is detected	Yes, same schema	Yes, if you add checks	Needs a parser that keeps layout and structure

The last row is the pattern that holds up, and it is what an agentic IDP does. For tools that implement these patterns, see the best document parsing APIs.

The solution: an agentic IDP with OCR

Parse every page on its own, in parallel. OCR and layout analysis split each page into blocks (text, tables, figures, headers, footers) and fix the reading order. Each page is independent, so 300 pages are 300 small jobs and not one huge one. Scans go through OCR first.
Extract across the whole set of parsed blocks. An agentic extractor looks at the blocks of every page, recognizes which table fragments belong to the same table and joins them in order, and reads document-level fields from wherever they sit.

The table field is an object field with nested columns:

{
  "name": "line_items",
  "description": "One row per line of the table, across all pages",
  "data_type": "object",
  "nested_fields": [
    { "name": "description", "data_type": "string", "description": "Item description" },
    { "name": "quantity", "data_type": "integer", "description": "Quantity ordered" },
    { "name": "unit_price", "data_type": "float", "description": "Price per unit" },
    { "name": "line_total", "data_type": "float", "description": "Row total amount" }
  ]
}

Try it on your own long document: the Free tier includes 50,000 credits with no credit card, enough to run a long file through this workflow.

It also works for RAG. If the goal is retrieval and not fields, the same parse step gives you the document as structured text with tables kept whole, ready to index. See PDF to markdown for LLMs.

How to check nothing is missing when you extract data from a long PDF

A long document makes silent loss easy, so build the check into the workflow:

Count the rows. If the document says "42 items", the extraction should have 42 rows. A different count flags the document.
Make the totals close. The sum of the line totals should match the printed subtotal, and subtotal plus tax should match the grand total. A validation step can run these rules on every document.
Look at the confidence of the rows that matter. Set a threshold and route what falls below it to a person who sees the source page next to the value.
Check the seams. Open the page breaks of one test document by hand: the last row of a page and the first of the next are where a table is most likely to be cut or duplicated.

Evidence on each value is what makes the manual check fast: the reviewer clicks a value and lands on the page it came from. See why grounding makes extraction auditable.

What it costs with anyformat

100-page document	Credits	Business (€0.001 per credit)	Free / pay-as-you-go (€0.0015)
Standard Parse + Standard Extract	6,000	€6.00	€9.00
Agentic Parse + Agentic Extract	25,000	€25.00	€37.50

Limits, stated plainly

Scans and photos lower accuracy for every method. Use a confidence threshold and a review step for them.
Agentic mode does not support multi-file documents yet (several files treated as one document). Combine files before upload or process them separately.
Very irregular tables (merged cells, tables that change columns halfway) need a test on your own files before you trust them.
Accuracy depends on your documents. Before you rely on any vendor's headline figure, ours included, test fifty of your own, count rows against the source and measure field-level accuracy.

How to choose

Frequently asked questions

How do I know no rows were dropped? Count the rows against the document, make the totals close, and review low-confidence values with their source page open.

Can I use this for RAG? Yes: the parse step returns the document as structured text with tables kept whole, ready to index.

How much does it cost per page? At Standard rates, 60 credits per page (€0.06 on Business); at Agentic rates, 250 credits per page (€0.25 on Business).

Disclosure: anyformat sells document extraction; the comparison criteria and dates are stated.

Originally published at anyformat.ai/blog/extract-data-from-long-pdfs-llm.

Invoice data extraction API: how to extract invoices to JSON

Felipe Cardona — Wed, 14 Oct 2026 13:00:19 +0000

An invoice data extraction API takes an invoice as a PDF or image and returns structured JSON: header fields such as invoice number, vendor, dates and totals, plus the line items, each value with a confidence score and, in the better ones, the place on the page it was read from. With anyformat you describe the fields once as a schema, run a workflow, and read the result. This guide shows the full flow with code, what comes back, what it costs, and how it compares with the other ways of doing it. Last evaluated: October 2026.

What an invoice extraction API should return

For accounts payable the useful output is not text, it is a record you can post to an ERP or accounting system:

Header fields: invoice number, vendor name, issue date, due date, currency, subtotal, tax amount, total amount.
Line items: description, quantity, unit price and amount for each row.
A confidence score per value, so you can decide what is posted automatically and what a person checks.
Evidence: the text and page each value came from, so a reviewer can verify it in seconds instead of rereading the invoice.
No invented values: when a field is not on the document, the right answer is empty, not a guess.

The last two are what separate an extraction API from OCR with a script on top. See how to extract structured data from a PDF with an LLM for the general case.

The flow: three calls

The API has three steps. Create a workflow with a schema, upload an invoice against it, and fetch the result.

1. Create the workflow (a parse node and an extract node, connected):

curl -X POST 'https://api.anyformat.ai/v3/workflows/' \
  -H "Authorization: Bearer $ANYFORMAT_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Invoice extractor",
    "nodes": [
      { "id": "parse_1", "type": "parse" },
      {
        "id": "extract_1",
        "type": "extract",
        "extraction_schema": {
          "fields": [
            { "name": "invoice_number", "description": "Invoice ID printed on the document", "data_type": "string" },
            { "name": "vendor_name", "description": "Company that issued the invoice", "data_type": "string" },
            { "name": "issue_date", "description": "Date the invoice was issued", "data_type": "date" },
            { "name": "due_date", "description": "Payment due date", "data_type": "date" },
            { "name": "subtotal", "description": "Total before tax", "data_type": "float" },
            { "name": "tax_amount", "description": "Total tax", "data_type": "float" },
            { "name": "total_amount", "description": "Grand total to pay", "data_type": "float" },
            { "name": "currency", "description": "Currency of the amounts", "data_type": "enum",
              "enum_options": [
                { "name": "USD", "description": "US dollar" },
                { "name": "EUR", "description": "Euro" },
                { "name": "GBP", "description": "Pound sterling" }
              ] },
            {
              "name": "line_items",
              "description": "One row per line on the invoice",
              "data_type": "object",
              "nested_fields": [
                { "name": "description", "data_type": "string" },
                { "name": "quantity", "data_type": "integer" },
                { "name": "unit_price", "data_type": "float" },
                { "name": "amount", "data_type": "float" }
              ]
            }
          ]
        }
      }
    ],
    "edges": [ { "source": "parse_1", "target": "extract_1" } ]
  }'  # returns { "id": "<workflow_id>", ... }

2. Upload an invoice and run it:

curl -X POST "https://api.anyformat.ai/v3/workflows/<workflow_id>/upload/run/" \
  -H "Authorization: Bearer $ANYFORMAT_API_KEY" \
  -F "files=@invoice.pdf"  # returns 202 { "run_id": "<run_id>", "document_packet_id": "...", "workflow_id": "...", "status": "queued" }

3. Fetch the result. The endpoint always answers 200; the status field tells you where the run is (queued, in_progress, processed, error or cancelled), and the results appear once it is processed:

curl -H "Authorization: Bearer $ANYFORMAT_API_KEY" \
  "https://api.anyformat.ai/v3/runs/<run_id>/"

The same flow as a Python function, with polling and backoff (install the library first with pip install requests):

import os
import time
import requests

API = "https://api.anyformat.ai"
HEADERS = {"Authorization": f"Bearer {os.environ['ANYFORMAT_API_KEY']}"}


def extract_invoice(path: str, workflow_id: str) -> dict:
    with open(path, "rb") as f:
        run = requests.post(
            f"{API}/v3/workflows/{workflow_id}/upload/run/",
            headers=HEADERS,
            files={"files": f},
            timeout=60,
        )
    run.raise_for_status()
    run_id = run.json()["run_id"]

    url = f"{API}/v3/runs/{run_id}/"
    delay = 4
    for _ in range(60):
        res = requests.get(url, headers=HEADERS, timeout=30)
        res.raise_for_status()
        body = res.json()
        status = body["status"]
        if status == "processed":
            return body["results"]["extractions"][0]["fields"]
        if status in ("error", "cancelled"):
            raise RuntimeError(f"Run {run_id} ended with status {status}")
        time.sleep(delay)  # queued or in_progress
        delay = min(delay * 2, 30)
    raise TimeoutError("Invoice still processing after 60 attempts")


fields = extract_invoice("invoice.pdf", workflow_id="<workflow_id>")
print(fields["invoice_number"]["value"], fields["total_amount"]["value"])

Submissions are limited to 60 requests per minute and the other endpoints to 600. Send an Idempotency-Key header on POST requests so a retry does not duplicate work. See the API reference.

What comes back

Every field in results.extractions[0].fields returns its value, a confidence score, a verification status and the evidence it was read from. Real output for a fictional invoice, trimmed to two header fields and the first line item:

{
  "invoice_number": {
    "value": "INV-2026-0417",
    "value_override": null,
    "verification_status": "not_verified",
    "confidence": 91.0,
    "evidence": [
      {
        "text": "Invoice number: INV-2026-0417\nIssue date: 2026-09-15\nDue date: 2026-10-15",
        "page_number": 1
      }
    ]
  },
  "total_amount": {
    "value": "2141.7",
    "value_override": null,
    "verification_status": "not_verified",
    "confidence": 92.0,
    "evidence": [
      {
        "text": "Total due (EUR) 2,141.70",
        "page_number": 1
      }
    ]
  },
  "line_items": [
    {
      "description": {
        "value": "Cloud hosting, September",
        "value_override": null,
        "verification_status": "not_verified",
        "confidence": 98.0,
        "evidence": [
          {
            "text": "Cloud hosting, September | 1 | 1,200.00 | 1,200.00",
            "page_number": 1
          }
        ]
      },
      "amount": {
        "value": "1200.0",
        "value_override": null,
        "verification_status": "not_verified",
        "confidence": 98.0,
        "evidence": [
          {
            "text": "Cloud hosting, September | 1 | 1,200.00 | 1,200.00",
            "page_number": 1
          }
        ]
      }
    }
  ]
}

Three details that save debugging time:

Values arrive as strings, even for numbers and dates. Cast them with the data type you declared.
null means not found. The model does not invent a value when the document does not contain it; use the confidence score to decide what to review.
Line items come back as a list of rows. fields["line_items"] is a list with one entry per row of the invoice, and each entry maps a column name (description, quantity, unit_price, amount) to a cell with the same shape as any other field: value, confidence and evidence.

A confidence score is only useful if you act on it: set a threshold, post the invoices above it automatically, and send the rest to a person who sees the evidence next to the value.

Ways to extract invoice data, compared

Approach	Invoice fields	Line items	Custom fields	Confidence and evidence	Price (list, date checked)
OCR plus regex or templates	Per vendor layout	Fragile	New template each time	No	Your engineering time
AWS Textract AnalyzeExpense	Prebuilt	Yes	Limited	Per-field confidence	$10 per 1,000 pages, $0.01 per page up to 1 million pages, US West (Oregon) (AWS pricing page, read 2026-10-07, our Textract comparison)
Google Document AI invoice parser	Prebuilt	Yes	Custom extractor	Per-field confidence	$0.10 per document of up to 10 pages, so $0.10 for a one-page invoice (Google Cloud pricing page, read 2026-10-07, our Google comparison)
Azure Document Intelligence prebuilt invoice	Prebuilt	Yes	Needs labeled training data	Per-field confidence	$10 per 1,000 pages for all prebuilt models, invoices included (Azure pricing page, read 2026-10-07, our Azure comparison)
Schema-based extraction (anyformat)	Any schema you define	Object field with nested columns	A schema change, no retraining	Per value, with evidence	Credits per page and per operator (below)

AWS Textract and Azure list their prebuilt invoice models at $10 per 1,000 pages, which is cheaper per page than a schema-based API, and they are a good fit when your invoices match their model and you stay on one cloud. Google bills by document, $0.10 for up to 10 pages, so one-page invoices cost more per page there than anywhere else in this table. The trade-off for all three is custom fields: a field they did not anticipate means training or a second tool.

What it costs

Pricing is credit-based, per page and per operator. At list rates, Standard Parse is 25 credits and Standard Extract 35 credits per page, so one invoice page is 60 credits. A credit costs €0.001 on Business and €0.0015 on Free and pay-as-you-go: that is €0.06 per page on Business, or €60 per 1,000 pages, and €0.09 per page on pay-as-you-go. Agentic mode, for dense or complex invoices, costs 100 credits for Parse and 150 for Extract. The Free tier includes 50,000 one-time credits with no credit card, which covers about 800 single-page invoices at Standard rates.

That is more per page than the AWS and Azure prebuilt invoice models at $10 per 1,000 pages. The difference buys a schema you control, evidence for every value, and the same API for other document types. Run the numbers on your own volume before choosing.

Limits, stated plainly

Scans and photos: accuracy drops with skew, noise and handwriting. Use a confidence threshold and a review step for those.
Multi-page invoices: test one long invoice from each supplier you handle; dense tables across pages are what Agentic mode is for, and Agentic mode does not support multi-file documents yet.
Several invoices in one PDF: add a split step so each invoice is extracted separately, and read extractions, which lists one entry per detected document.
Invoices are business and sometimes personal data. Zero data retention is an Enterprise option that has to be enabled for your organization, so on the Free and Business plans use fictional invoices for tests and read our GDPR guide.
Accuracy depends on your documents. Before you rely on any vendor's headline figure, ours included, test fifty of your own invoices and measure field-level accuracy and the share that pass with no human touch.

How to choose an invoice extraction API

If your invoices match a prebuilt model and you live in one cloud, start with that cloud's invoice parser. If you need custom fields, several suppliers with different layouts, or evidence a reviewer can check, a schema-based API is the better fit. Ask every vendor the same question: when a value is wrong, what does my team see? For the broader process, see invoice processing with anyformat and the accounts payable page.

Frequently asked questions

What is an invoice data extraction API?
An API that receives an invoice (PDF or image) and returns structured data, usually JSON with header fields, line items and a confidence score per value.

How do I extract line items from an invoice?
Define a line_items field of type object with nested fields (description, quantity, unit price, amount). The API returns one row per line, each cell with its own confidence and evidence.

Does it work with scanned invoices?
Yes, with OCR before extraction. Scans and photos are the weak spot of every approach, so set a confidence threshold and review what falls below it.

What format does the API return?
JSON. Values arrive as strings and you cast them using the data type you declared; a value that is not on the invoice comes back as null.

How is it priced?
Per page and per operator in credits. At Standard rates one invoice page is 60 credits, or €0.06 on Business.

Can I process many invoices at once?
Yes: run the workflow once per file and poll each run. Submissions are limited to 60 requests per minute.

Start with your hardest documents. Upload the invoices that break your current pipeline, define the fields you need, and see the values with their confidence and their evidence on the page. The Free tier includes 50,000 credits with no credit card.

Disclosure: anyformat sells document extraction; the example is fictional and the comparison criteria and dates are stated.

Originally published at anyformat.ai/blog/invoice-data-extraction-api.

How to extract data from bank statements automatically

Felipe Cardona — Wed, 14 Oct 2026 09:00:27 +0000

You extract data from bank statements automatically by reading each PDF or scan into a structured schema (account holder, account number, period, opening and closing balance, and one row per transaction) and then checking that the arithmetic closes: opening balance plus credits minus debits must equal the closing balance. The first step is the easy part. The check is what tells you whether to trust the output, because a bank statement is a long table where one dropped row looks exactly like a correct one.

This guide walks through the problem, the main ways people solve it, and a worked example with a fictional statement. Last evaluated: October 2026. For long statements, see how we handle multi-page documents; for finance teams, see anyformat for financial services.

Why bank statements are harder than they look

A bank statement looks like a clean table, and that is the trap. Five things make it hard to extract reliably:

Every bank lays it out differently. Column order, date formats, whether debits and credits are separate columns or one signed column, and where the opening balance sits all change from bank to bank, and often between a bank's own products.
Transactions run across pages. The table breaks at the page boundary, headers repeat or disappear, and a row can be cut in two.
Descriptions wrap onto several lines. A naive parser reads the second line of a description as a new, empty transaction.
Scans and photos. Many statements arrive as scans or phone photos, with skew, noise and stamps over the numbers.
Several accounts or statements in one file. A single PDF can hold more than one account, or more than one month.

None of this is a reason to avoid automation. It is the reason the output needs a check built in.

What you want out: a schema

Start from the output, not from the tool. For a typical current-account statement:

Field	Type	Notes
account_holder	text	As printed
account_number	text	IBAN or local format, as printed
period_start, period_end	date
opening_balance, closing_balance	number	With currency
transactions[]	list	One entry per row
transactions[].date	date	Booking date; keep the value date if both exist
transactions[].description	text	Joined across wrapped lines
transactions[].debit, .credit	number	Or one signed amount, pick one convention
transactions[].balance	number	Running balance, when the statement prints it

A fictional example of the result for one page (all values invented):

{
  "account_holder": "Northwind Trading Ltd",
  "account_number": "ES00 0000 0000 0000 0000 0000",
  "period_start": "2026-09-01",
  "period_end": "2026-09-30",
  "opening_balance": 12480.15,
  "closing_balance": 11902.40,
  "transactions": [
    { "date": "2026-09-02", "description": "Transfer from ACME SA, invoice 1043", "credit": 3200.00, "balance": 15680.15 },
    { "date": "2026-09-03", "description": "Card payment, Office Supplies Co", "debit": 84.90, "balance": 15595.25 },
    { "date": "2026-09-05", "description": "Direct debit, Utilities Ltd, September", "debit": 312.60, "balance": 15282.65 }
  ]
}

Ways to extract bank statement data, compared

Approach	Handles different banks	Handles scans	Catches wrong rows	Typical limit
Copy and paste into a spreadsheet	Yes, by hand	No	Only if you check	Hours per batch, error-prone
Template or rules per bank	One template per layout	Poorly	No	Breaks when a bank changes its PDF
Generic OCR plus a table library	Partly	Yes	No	Tables with merged or wrapped cells fail silently; see our table-library test
Prompting a general LLM with the file	Yes	Yes	No	Fluent output with no signal for a wrong row; see how to reduce hallucinations
A bank-statement specialist (for example DocuClipper)	Yes, built for financial formats	Not stated in our comparison	Not stated	Narrow to financial documents; flat monthly tiers (Starter $20 for 60 pages, Business $111 for 640, Enterprise $360 for 2,000), no on-premise or EU residency in its published docs (as-of 2026-09-14, our Nanonets comparison)
A pretrained document-AI platform (for example Docsumo)	Pretrained bank-statement model; custom types need about 20 training samples	Not stated in our comparison	Not stated; 99%+ on bank statement data is vendor-reported and unaudited	Pricing on quote (anyformat vs Docsumo)
A document platform with validation	Yes	Yes	Yes, if you configure the check	You define the schema and the rules once

The column that matters is "Catches wrong rows". Every method on this table reads a statement. Few tell you which rows to distrust.

How to extract data from a bank statement with anyformat, step by step

The same statement runs through four steps in an anyformat workflow, built in Studio as a three-operator flow: Parse, Extract and Validate.

Parse. The file becomes structured pages and tables, with each block tied to its position on the page and a confidence score on each table. Scans go through OCR first. In this workflow Parse runs in Agentic mode.

Extract. You describe the schema above in plain language. Header fields come out as single values, and the transactions come out as a list with one entry per row. Extract runs in Agentic mode here, with the 8 fields of the schema. Each field shows its type, whether it is verified, and the review threshold you set. Agentic mode does not support multi-file documents yet.

Validate. Rules check the result against itself: opening balance plus credits minus debits must equal closing balance; each running balance must follow from the previous one; every transaction date must fall inside the statement period; transactions must be in chronological order; a row cannot hold both a debit and a credit; and values under the confidence threshold are flagged for review. The Validation view shows each rule with its result and the values it checked, and you can test an expression before you rely on it.

Review what is doubtful. Every extracted value carries a confidence score you can set a threshold on and a link to the place on the page it was read from. Rows under the threshold, or any statement whose balance check fails, go to a person who sees the source next to the value.

What this changes in practice: you do not read every row. You read the rows the check or the confidence flags, and everything else flows through.

Try it on your own statements: the Free tier includes 50,000 credits, enough to run this workflow on a batch of fictional or consented statements without a credit card.

How to convert a bank statement to Excel or CSV

Once the transactions are structured, the Excel or CSV export is the easy part: each transaction becomes a row, with date, description, debit, credit and balance as columns, and the header fields (account holder, account number, period, opening and closing balance) go in a summary sheet or repeat on every row, whichever your accounting tool expects. The step that decides whether the spreadsheet is usable is the one before it: a spreadsheet built from an unchecked extraction hides its errors in plain sight. Run the balance check first, then export only the statements that pass, and send the rest to review.

A balance check, spelled out

If the opening balance is 12,480.15, credits total 3,200.00 and debits total 3,777.75, the closing balance must be 11,902.40. If the extraction returns 11,818.00, one row is wrong or missing and the statement is flagged, instead of the error reaching your ledger. The same logic catches a dropped row, a misread digit and a duplicated line. (The figures are the fictional ones from the JSON above, extended to a full month.)

Statements are personal data

Bank statements carry personal and financial data. Use fictional or consented documents for tests, keep production data inside a deployment you control, and check where each tool processes it. anyformat is ISO 27001:2022 certified, offers EU data residency and can run self-hosted or air-gapped. Zero data retention is an Enterprise option that has to be enabled for your organization, so on the Free and Business plans treat uploaded documents as stored and use fictional statements for tests. More on residency in our GDPR guide.

What it costs

Pricing is credit-based, per page and per operator. At list rates, Parse costs 25 credits per page in Standard mode and 100 in Agentic; Extract costs 35 in Standard and 150 in Agentic; and each AI validation rule costs 5 credits, charged once per extraction and never per page. A credit costs €0.001 on Business and €0.0015 on Free and pay-as-you-go.

10-page statement, 6 AI validation rules	Credits	Business (€0.001 per credit)	Free / pay-as-you-go (€0.0015)
Standard Parse + Standard Extract	630	€0.63	€0.95
Agentic Parse + Agentic Extract	2,530	€2.53	€3.80

The Free tier includes 50,000 one-time credits with no credit card, and Business includes 500,000 credits a month. Standard mode is the right starting point for clean digital statements; Agentic is for scans and layouts that Standard gets wrong.

Limits, stated plainly

Handwriting and very low-quality photos are the weak spot of every approach. Set a confidence threshold and let a person review those.
Statements with unusual structures (multi-currency accounts on one page, summary pages that repeat totals) need a test on your own files before you trust them.
The balance check only works when the statement prints balances. Some formats print only movements; then the check compares totals, not running balances.
We have not published an accuracy figure for bank statements. Test fifty of your own statements, measure field-level accuracy and the share that pass with no human touch.

How to choose

If you process a handful of statements a month in one layout, a template or a converter is enough. If layouts vary, scans are common, or an error in a ledger is expensive, choose a tool where a failed check is visible: the question to ask every vendor is "when a balance does not close, what does my team see?". For broader comparisons see the best document parsing APIs and alternatives to Nanonets.

Frequently asked questions

How do I extract data from a bank statement PDF automatically?
Read the file into a schema (header fields plus one row per transaction), then verify that opening balance plus movements equals closing balance. Tools differ mainly in whether they tell you which rows to distrust.

Can I extract data from a scanned bank statement?
Yes, with OCR before extraction. Accuracy drops with skew, noise and photos, so scanned statements need a confidence threshold and a review step.

Can I convert a bank statement to Excel or CSV?
Yes: once the transactions are structured, exporting to CSV or Excel is a formatting step. The hard part is the extraction and the check, not the export.

How do I know the extracted transactions are correct?
Run the balance check. If opening balance plus credits minus debits does not equal the closing balance, a row is wrong or missing. Per-field confidence tells you where to look first.

Is it safe to upload bank statements to an extraction tool?
Check retention, residency and certifications before you upload real data, and test with fictional statements first.

Does it work for statements from different banks?
Template-based tools need one template per layout. Schema-based tools read each layout from your field definitions, but you should still test a sample from each bank you handle.

Start with your hardest documents. Upload the statements that break your current pipeline, define the fields you need, and see the values with their confidence and their evidence on the page. The Free tier includes 50,000 credits with no credit card.

Disclosure: anyformat sells document extraction; the example is fictional and the comparison criteria are stated.

Originally published at anyformat.ai/blog/extract-data-from-bank-statements.

The 8 Best AWS Textract Alternatives in 2026

Felipe Cardona — Wed, 07 Oct 2026 07:58:00 +0000

The best AWS Textract alternatives in 2026 are anyformat, Google Document AI, Azure Document Intelligence, ABBYY, Nanonets, Reducto, LlamaParse and Unstructured. Teams leave Textract for four reasons: it returns raw OCR rather than fields in your schema, it ships no workflow, review or evaluation layer, it runs only inside AWS regions under US jurisdiction, and its pricing is split across per-page APIs that are hard to forecast. Two of the eight, anyformat and Reducto, can be deployed on-premise in an air-gapped environment; if that is the constraint driving your search, start there.

To be clear about what Textract does well: it is a mature OCR service with strong table detection, dedicated APIs for forms, expenses and identity documents, and native integration with S3, Lambda and Step Functions. If your documents are structured forms and your stack is fully AWS, it remains a serious option.

Method. We evaluated each tool in July 2026 on five criteria: custom field extraction without training data, on-premise deployment, European data sovereignty, workflow orchestration, and pricing model. Facts come from vendor documentation, third-party benchmarks, and our own benchmark on 1,000+ real documents.

Comparison at a glance

Tool	Best for	Custom fields without training	On-premise	EU sovereignty	Pricing model
anyformat	Custom schemas on complex documents, with accuracy you can measure	Yes (zero-shot)	Yes, incl. air-gapped	EU-native	Per page, per operator ($25/1,000 pages parsing)
Google Document AI	GCP-native pipelines, 200+ languages	Yes (Custom Extractor foundation model)	No	US jurisdiction, GCP regions	Per page, per processor
Azure Document Intelligence	Microsoft-stack teams	No (5+ labeled docs + training)	Partial (containers)	US jurisdiction, Azure regions	Per page, per model
ABBYY	Large IDP deployments with stable document types	No (Skills + training)	Yes (FlexiCapture)	US-headquartered	License + services
Nanonets	No-code automation for mid-market teams	Partial (HITL annotation)	Enterprise contract only	US-based multi-tenant	Per block run ($0.02‚Äì$0.30)
Reducto	Engineering teams building custom pipelines	Yes (code-defined schemas)	Yes (VPC, air-gapped)	US-based, EU endpoints	Flat $10 / 1,000 pages for parsing (r-1, Sep 2026); extraction and add-ons priced separately
LlamaParse	Parsing documents into LLM-ready Markdown	Partial (parsing-first)	Enterprise self-hosted	US-based cloud	Per page (credits); +10 credits per page containing a form
Unstructured	RAG chunking, 71+ connectors	No (element arrays)	Yes (self-hosted)	US-based	API + self-hosted

1. anyformat

If you're looking for an AWS Textract alternative that gives you custom-schema extraction with no training data, a workflow and evaluation layer built in rather than assembled from Lambda and Step Functions, and EU-native jurisdiction instead of a US-governed AWS region, anyformat is built for exactly that gap. It's a European document automation platform that covers the whole pipeline a Textract replacement needs: extraction from a schema with no training data, workflow orchestration, human review, and accuracy evaluation, in one product. You define the fields you want and extraction works on the first document.

In anyformat's published July 2026 benchmark on 1,000+ real documents, anyformat scored 78.1% on parsing quality at $25 per 1,000 pages; Textract scored 65.4% on the same set.

Every extracted value returns a calibrated confidence score together with the evidence it was read from, the review interface highlights that evidence on the page, and a confidence threshold routes uncertain fields to a person while the rest go straight through. Deployment covers cloud, private cloud, on-premise and fully air-gapped environments, and ISO 27001:2022 certification, GDPR tooling and zero-retention processing are included on every plan with no surcharge.

If you need to know whether accuracy is holding up over time, anyformat ships that built in: a dataset of verified ground truth, versioned evaluations that score any workflow change field by field against it, and live production accuracy, confidence and through-rate side by side. Optimizer then improves a workflow's field descriptions automatically against that same dataset. On Textract, that measurement harness is something your team builds and maintains.

Pricing is credit-based, charged per page and per operator: Parse 25 credits per page, Extract 35, Classify 10, Split 25, with agentic variants at 100 and 150; on the Business plan 10 credits cost ‚Ç¨0.01, so the $25 per 1,000 pages above is the parsing rate. The free tier includes 50,000 credits with no credit card.

Best for: teams that need custom fields on complex documents with accuracy they can measure, and a review step their operations team can run without code.

2. Google Document AI

Google Document AI is GCP's document processing service, a natural fit for teams already on Google Cloud with standard document types. Its Enterprise Document OCR supports 200+ languages with handwriting recognition in 50, per Google's documentation, and it integrates tightly with BigQuery and Vertex AI. Custom fields no longer require labeling to get started: the Custom Extractor runs on a foundation model that extracts from a schema alone, with few-shot accepting up to 5 examples and fine-tuning requiring 50 training plus 50 test documents to reach production accuracy. The constraints are elsewhere: system limits cap many online processing requests at 15 pages, deployed custom processor versions carry hosting fees, and there is no on-premise option. In our parsing benchmark it scored 55.0%, with plain OCR at $1.50 per 1,000 pages, the lowest cost among the cloud providers we tested. See the full anyformat vs Google Document AI comparison.

Best for: GCP-native teams whose documents fit the online page limits and who want custom fields without a labeling project.

3. Azure Document Intelligence

Azure Document Intelligence, formerly Form Recognizer, is Microsoft's document processing service and the default path for organizations on the Azure stack. Its pretrained models for invoices, receipts, IDs and tax forms are among the strongest cloud offerings: it scored 69.9% in our parsing benchmark, ahead of both Textract (65.4%) and Google Document AI (55.0%). Custom fields require labeled documents in Document Studio, five examples minimum per Microsoft's documentation and usually more, plus a training cycle; container deployment covers only a subset of features, and configuration spreads across Document Studio, the Azure portal and API code. See the full anyformat vs Azure Document Intelligence comparison.

Best for: Microsoft-stack teams whose documents match Azure's pretrained models.

4. ABBYY

ABBYY is the longest-standing enterprise IDP vendor on this list, founded in 1989 and aimed at large organizations with stable, high-volume document processes. Its catalog lists 150+ pre-built extraction Skills across two products: Vantage (cloud) and FlexiCapture, one of the most mature on-premise capture systems available. The trade-off is the delivery model: implementations typically run weeks to months with third-party integrators, professional services budgets range from $15K to $200K+, and contracts often require 3-year terms with annual prepayment. Documents outside the Skill library need custom model training. See the full anyformat vs ABBYY comparison.

Best for: Enterprises with stable document portfolios, a hard on-premise requirement, and budget for a traditional deployment.

5. Nanonets

Nanonets is a mid-market document automation platform, founded in 2017, aimed at teams that want no-code workflows without an engineering project. Its block-based workflow builder (import, data-action and export blocks) is well designed for non-technical users, and published pricing runs $0.02 to $0.30 per block run, with Nanonets' own pricing page putting a typical invoice workflow at four to six block runs per document. Nanonets' documentation notes that out-of-box models may require human-in-the-loop annotation to reach production accuracy on non-standard documents. Default deployment is US-based multi-tenant cloud, on-premise is available only via enterprise contract, and data may be retained for around 30 days after termination. See the full anyformat vs Nanonets comparison.

Best for: Mid-market teams automating standard document types at moderate volume, without strict EU sovereignty requirements.

6. Reducto

Reducto is a US-based document parsing API, founded around 2023, built for engineering teams that want a high-accuracy parsing primitive with full code control. It has raised $108M in total, most recently a $75M Series B led by a16z in October 2025; it publishes the open RD-TableBench table benchmark and offers Parse, Split, Extract and Edit endpoints with cloud, VPC and on-premise deployment including air-gapped environments. Extraction schemas need no training data, and since 2026 its Studio adds a visual pipeline builder, auto-generated schemas and evaluations on its Growth tier. What it still lacks is a human review queue with reviewer roles and per-field verification status, so the review step is yours to build. Since September 2026 its r-1 model parses at a flat $10 per 1,000 pages. It holds SOC 2 Type II and offers HIPAA processing with a BAA on higher tiers, but does not list ISO 27001, a frequent blocker in European procurement. See the full anyformat vs Reducto comparison.

Best for: Engineering teams replacing Textract's parsing layer inside a custom-built pipeline.

7. LlamaParse

LlamaParse is LlamaIndex's document parsing API, launched in February 2024, built to turn documents into LLM-ready Markdown for RAG pipelines. Speed is its standout trait: an independent Procycons benchmark measured around 6 seconds for both 1-page and 50-page documents in batch mode. The limits show up in structured extraction: Markdown output flattens merged cells and nested table relationships; confidence scores left beta in August 2026 and are documented as calibrated on three of its five parsing tiers, self-reported without a published evaluation, with no review queue to act on them; the standard offering is US cloud-only with enterprise self-hosting via Kubernetes. It holds SOC 2 Type 2 but does not list ISO 27001. See the full anyformat vs LlamaParse comparison.

Best for: Fast RAG ingestion inside the LlamaIndex ecosystem, not field-level extraction into business systems.

8. Unstructured

Unstructured is a partially open-source parsing platform that chunks documents into element arrays for RAG pipelines, aimed at AI teams building retrieval systems. It has the widest connector ecosystem in the category, with 71+ connectors including Databricks, Elasticsearch, S3 and Google Drive, and its commercial platform holds SOC 2 Type II, ISO 27001 and HIPAA certifications (the open-source library is not in scope) with a self-hosted deployment option. The key caveat: it does not do field-level structured extraction, so if you need invoice totals or contract dates in your ERP, it solves a different problem. The Procycons 2025 benchmark also measured 51 seconds to process a single page, versus about 6 for the fastest alternatives. See the full anyformat vs Unstructured comparison.

Best for: RAG preparation with maximum connector coverage; complementary to, not a replacement for, an extraction platform.

How to choose the right one for your needs

If your whole stack is on AWS and your documents are structured forms, Textract remains viable: the switching cost may not be worth it yet.
Count the full pipeline cost, not just the page price: post-processing, validation, routing, a review UI and monitoring all cost engineering time to build if the vendor doesn't ship them.
If you need custom fields without training data, anyformat (schemas defined in Studio), Reducto (code-defined) and Google's Custom Extractor all work from a schema alone.
If you need to measure accuracy over time, look for a vendor with a dataset-backed evaluation tool, not a one-off benchmark number.
If documents can't leave your infrastructure, anyformat, Reducto, ABBYY FlexiCapture, or a self-hosted Unstructured deployment all support that.
If EU governing law is a hard requirement, only an EU-headquartered vendor actually changes the jurisdiction. An EU region on a US company doesn't.
If your ops team needs to own the workflow without engineering, look for a visual builder (anyformat Studio, Nanonets' block editor).
If you're building for RAG, LlamaParse or Unstructured are built specifically for that output shape.

Frequently asked questions

What is the best alternative to AWS Textract?
It depends on the constraint driving the switch. For an end-to-end platform with zero-shot extraction, workflow orchestration, human review and built-in evaluation, anyformat is the most complete option. For a code-first parsing API, Reducto is the closest fit. Teams consolidated on Google Cloud or Azure usually evaluate their own provider's document service first.

What is the best European alternative to AWS Textract?
anyformat is the only EU-native platform on this list: European governance, ISO 27001 certification covering the processing pipeline, zero-retention processing, and on-premise deployment including air-gapped environments. US providers offer EU regions, but region selection changes where data sits, not the jurisdiction that governs it.

Is there an open-source alternative to AWS Textract?
Partially. Unstructured has an open-source core, and self-hosted engines like Docling and PaddleOCR are free to run. In our parsing benchmark both scored below Textract (52.3% and 43.2% versus 65.4%), so budget for accuracy validation and the engineering effort to operate them in production.

Why do teams switch away from AWS Textract?
Four reasons come up consistently: Textract returns raw OCR that needs a custom post-processing pipeline before applications can use it; it has no workflow or evaluation layer, so orchestration and accuracy monitoring mean assembling Lambda, Step Functions, queues and your own measurement harness; pricing splits across per-page APIs, with combined forms and tables analysis at $65 per 1,000 pages and $70 with queries added (AWS pricing, 2026); and the service is governed under US jurisdiction regardless of region selection.

Is there an on-premise or self-hosted alternative to AWS Textract?
Yes: anyformat and Reducto both offer on-premise deployment including air-gapped environments, ABBYY FlexiCapture is a mature on-premise capture system, and Unstructured can be self-hosted, while Textract itself runs only inside AWS regions.

Which AWS Textract alternative works without training data?
anyformat, Reducto and Google's Custom Extractor extract from a schema alone, while Azure Document Intelligence, ABBYY and Nanonets still require labeled example documents.

What does AWS Textract cost compared with the alternatives?
Textract's forms and tables analysis lists at $65 per 1,000 pages; among the alternatives, Reducto parses at a flat $10 per 1,000 pages, anyformat parses at $25 per 1,000 pages with extraction and classification priced separately per operator, and Google's plain OCR lists at $1.50 per 1,000 pages.

Does an EU region make AWS Textract GDPR-compliant?
An EU region can support GDPR compliance through in-region storage and standard contractual clauses, but it does not change which country's law governs the provider: a US company processing data in an EU region remains subject to US law regardless of where the servers sit. Buyers whose requirement is EU governing jurisdiction, not just GDPR compliance on paper, need an EU-headquartered vendor.

If you have narrowed the decision down to two options, start with the deep dive: anyformat vs AWS Textract compares extraction approach, workflow orchestration, sovereignty and pricing side by side.

Originally published at anyformat.ai/blog/best-aws-textract-alternatives.

OCR API vs open source

Felipe Cardona — Tue, 06 Oct 2026 09:37:54 +0000

Choosing between a managed OCR API and self-hosted open source comes down to one comparison: the monthly cost of the API at your volume, against the cost of running the open-source engine yourself, which is mostly the hours your team spends keeping it working. The prices below are public. The hours are yours, and they decide the answer.

This page gives the formula, the published API prices as of October 2026, a worked example and a checklist for the parts a formula does not cover.

What managed OCR APIs publish

All prices are US dollars at list price, per 1,000 pages, as read on 1 October 2026. Check the linked page before you decide, since prices change.

Service	Price per 1,000 pages	Free tier
Textract, text	$1.50 ($0.60 above 1M)	1,000 pages/month for 3 months
Textract, tables	$15 ($10 above 1M)	See pricing page
Azure Read	$1.50 ($0.60 above 1M)	500 pages/month
Google OCR	$1.50 ($0.60 above 5M)	First 1,000 pages
Mistral OCR 4.1	$4	See pricing page

Azure's pricing page did not display figures when we read it; the Azure figures come from Microsoft's Retail Prices API for the East US region. Mistral's batch discount lowers its price further, and many older articles still quote the price of its previous model, so check the current page. Textract and Azure also charge more for tables, forms and prebuilt extraction than for plain text, so compare the same capability across services.

What self-hosting costs

Two parts of the cost have a price you can look up, and the rest does not.

Infrastructure is the part with a public price. As an example, an AWS c6i.xlarge instance (4 vCPUs, 8 GiB) costs about $0.17 an hour on demand in us-east-1, close to $124.80 a month, according to the Vantage instance table, which mirrors AWS list prices; confirm it on the AWS pricing page. Block storage on gp3 is $0.08 per GB-month on the EBS pricing page. A GPU instance such as the g5.xlarge (one NVIDIA A10G) is about $1.006 an hour, close to $734 a month, per the same table.

The rest has no public price: the engineering time to build it, preprocessing and post-processing code, upgrades, monitoring and on-call, labelling a test set, security work, and a fallback for pages that fail. These are real costs, and they are the reason the decision is not just a comparison of price lists.

The formula

With P as pages per month and p as the API price per 1,000 pages, the API costs P / 1000 × p a month. Self-hosting costs the infrastructure plus the people: infrastructure and storage, plus the monthly hours of upkeep times your loaded hourly rate, plus the build hours and the labelling, spread over the months you expect to run it.

def monthly_cost_api(pages: int, price_per_1000: float) -> float:
    return pages / 1000 * price_per_1000

def monthly_cost_self_hosted(infra: float, upkeep_hours: float, hourly_rate: float,
                             build_hours: float = 0, labelling_cost: float = 0, months: int = 12) -> float:
    """Infrastructure, upkeep, and the one-off build and labelling spread over `months`."""
    one_off = build_hours * hourly_rate + labelling_cost
    return infra + upkeep_hours * hourly_rate + one_off / months

def break_even_rate(pages: int, price_per_1000: float, infra: float, upkeep_hours: float,
                    build_hours: float = 0, labelling_cost: float = 0, months: int = 12):
    """Hourly rate at which both options cost the same, or None when there is no labour to price."""
    labour_hours = upkeep_hours + build_hours / months
    if labour_hours == 0:
        return None  # compare infrastructure and labelling with the API cost directly
    return (monthly_cost_api(pages, price_per_1000) - infra - labelling_cost / months) / labour_hours

The loaded hourly rate is your number: salary, overhead and the opportunity cost of what else those hours could do. This page does not guess it. The code sets the build hours and the labelling cost to zero by default, so a call that leaves them out covers ongoing costs only and understates self-hosting; pass your own values to include the one-off work. With no upkeep and no build hours there is no labour to price, so break_even_rate returns None, and the comparison is just infrastructure against the API. A negative result means self-hosting costs more than the API even if the labour were free.

A worked example

Take 100,000 pages a month of plain text OCR. At $1.50 per 1,000 pages the API costs $150 a month, and at Mistral OCR 4.1's $4 it costs $400. Self-hosting on the c6i.xlarge with 100 GB of storage costs about $132.80 a month in infrastructure ($124.80 plus $8.00).

The infrastructure alone is almost the same as the cheapest API. So the question is how many hours it takes to keep the engine running. As an illustrative placeholder, assume 20 hours a month of upkeep. Then self-hosting is cheaper than the $1.50 API only if one hour of that work costs less than about $0.86 (the $17.20 difference divided by 20 hours). At that price of labour, self-hosting does not win. Against the $4 API the same arithmetic gives about $13.36 an hour, which is where your own rate starts to matter.

infra = 124.80 + 100 * 0.08                      # c6i.xlarge plus 100 GB of gp3 storage
print(monthly_cost_api(100_000, 1.50))           # 150.0
print(round(infra, 2))                            # 132.8
print(round(break_even_rate(100_000, 1.50, infra, 20), 2))  # 0.86

A GPU changes the picture only at high volume. A g5.xlarge at about $734 a month costs less than a $1.50 API only above roughly 489,000 pages a month, and less than a $4 API above roughly 183,500 pages a month, before any labour. These numbers are illustrations with sourced prices and placeholder hours; replace the hours and the rate with your own.

What the formula leaves out

Document types. Tesseract documents its own limits on skew, low resolution and tables, and a managed service may handle them differently. Measure on your files.
Data residency. Self-hosting keeps data in your network. Managed APIs often offer region choices, so check each vendor.
Latency and throughput. Measure them, and note that some vendors price batch and synchronous calls separately.
Team capacity. Someone has to own preprocessing, upgrades and monitoring.
Accuracy target. Test 50 of your own documents on each option: pick a mix that covers your best, median and worst scans, label the fields you care about, run all candidates on the same inputs and set the pass threshold before you look at results. The scoring code is in Is Tesseract accurate enough for production?.

Where anyformat fits

anyformat is a third option: a platform that returns typed fields with a confidence score and the source text and page, rather than raw OCR text. Its self-hosted and on-premise deployment is an Enterprise option with no public price, so it has no row in the formula above; ask for a quote if that is your case, and run the same 50 documents through it. See on-premise and air-gapped document extraction for how that deployment works.

Frequently asked questions

Is it cheaper to self-host OCR?
Only at high volume or when the hours to run it are small. At $1.50 per 1,000 pages the infrastructure costs about as much as the API for 100,000 pages a month, so labour decides.

How much does a managed OCR API cost?
Published list prices for plain text OCR were $1.50 per 1,000 pages at AWS Textract, Azure Document Intelligence and Google Document AI, and $4 at Mistral OCR 4.1, as of 1 October 2026. Tables, forms and prebuilt extraction cost more.

When does self-hosting make sense beyond cost?
When data cannot leave your network, when you need to run offline, or when you need control over the model and its version.

What is the break-even volume?
It depends on your hours and hourly rate. Use the formula on this page: the loaded hourly rate at which both options cost the same is the API cost minus the infrastructure, divided by the monthly hours.

How do I compare accuracy between options?
Test 50 of your own documents, score the fields you care about, run every candidate on the same inputs and set the threshold first.

Originally published at anyformat.ai/blog/ocr-api-vs-open-source-self-hosted.

Is Tesseract accurate enough for production?

Felipe Cardona — Tue, 06 Oct 2026 09:26:13 +0000

Tesseract is accurate enough for production when your documents look like the ones it was built for, clean printed pages at a sufficient resolution, and your check on your own files says so. It does not publish an accuracy figure, so nobody can answer the question for you, and the useful move is to measure it on a sample of your own documents before you commit.

This page covers what Tesseract says about itself, what independent tests found, the conditions that make it fail, and a short test you can run in an afternoon with a go or no-go threshold set in advance.

What Tesseract says about itself

Tesseract is an open-source OCR engine under the Apache 2.0 licence. It supports more than 100 languages and uses an LSTM-based engine. Its README gives no accuracy number. It says that to get better results you will often need to improve the quality of the image.

Its documentation on improving quality is specific about when accuracy drops:

Resolution. It works best on images of at least 300 DPI.
Binarisation. Its default method can be suboptimal when the page background is unevenly dark.
Skew. Line segmentation quality falls significantly if the page is too skewed.
Noise. Noise that binarisation cannot remove can cause accuracy to drop, and dark scan borders can be read as characters.
Tables. The documentation says it has a problem recognising text and data from tables without custom preprocessing.

Its FAQ says of handwriting that you can try, but it will not work very well, because Tesseract is designed for printed text.

What independent tests found

Few independent comparisons exist, and each has caveats.

A peer-reviewed benchmark by Hegghammer, published in the Journal of Computational Social Science in 2021 (DOI 10.1007/s42001-021-00149-1), compared Tesseract, Amazon Textract and Google Document AI on scans of English books and Arabic articles, with artificial noise added. It found the two cloud services substantially better than Tesseract, especially on noisy documents. The data are book and article scans from 2021, not invoices.

A vendor-run benchmark on receipts, published by ImageToTable and last reviewed on 18 August 2026, reports character error rates of 0.3347 for Tesseract on CPU, 0.2833 for EasyOCR and 0.2045 for PaddleOCR on the SROIE and CORD receipt datasets. It is run by a vendor, which says so, and it does not state the Tesseract version or preprocessing, so read it as one data point.

Neither result is yours. The same engine can do very well on clean scans and badly on skewed phone photos, which is why the test below matters more than any published figure.

When Tesseract works and when it breaks

It tends to work on clean, upright, printed text at 300 DPI or more with a plain background, such as a modern scanned letter or a typed form. It tends to break on skewed or low-resolution images, uneven backgrounds, noisy scans, tables, and handwriting. Layout analysis is a segmentation step you tune through its page segmentation modes, which range from 0 to 13, so results can change a lot with one setting.

Test it on 50 of your own documents

Pick 50 documents that cover your real mix: the best, the median and the worst scans you receive. Hand-label the fields you care about, such as invoice number, date and total, rather than the full text. Run Tesseract on all 50 with the same preprocessing, then score the results. Decide the pass threshold before you run it, so that the result does not shape the target.

Two measures cover most needs: the character error rate for free text, and an exact match for numbers, dates and identifiers.

def edit_distance(a: str, b: str) -> int:
    prev = list(range(len(b) + 1))
    for i, ca in enumerate(a, start=1):
        cur = [i]
        for j, cb in enumerate(b, start=1):
            cur.append(min(prev[j] + 1, cur[j - 1] + 1, prev[j - 1] + (ca != cb)))
        prev = cur
    return prev[-1]

def cer(expected: str, got: str) -> float:
    return edit_distance(expected, got) / max(len(expected), 1)

def field_matches(expected: dict[str, str], got: dict[str, str]) -> dict[str, bool]:
    return {k: got.get(k, "").strip() == v.strip() for k, v in expected.items()}

Report the results per document type and count the documents with any wrong critical field, because one wrong total can matter more than a hundred slightly noisy words. Fifty documents give a rough signal, not a guarantee, and a result from a small sample does not replace monitoring on production traffic.

A go or no-go checklist

The critical fields pass your threshold on the documents you actually receive, including the worst quarter.
Pages arrive at 300 DPI or you control the scanning, and you handle skew and background before OCR.
You do not depend on tables or handwriting, or you have a separate answer for them.
Someone owns preprocessing, upgrades and monitoring, which a managed service would otherwise carry.
A wrong value has a cost you can tolerate, or a check or review step catches it.

If the answers are mostly no, you have the options of better preprocessing, a different open-source engine, a managed OCR API or a document processing platform that returns typed fields with confidence. How the cost compares is covered in OCR API vs open source.

Where anyformat fits

anyformat is a document extraction platform that sits at the end of that list. It returns typed fields with a confidence score and the source text and page they came from, so a person reviews the uncertain ones. It is not a substitute for the test above: run the same 50 documents through any option you consider, ours included. For the metrics that matter once documents reach production, see beyond accuracy.

Frequently asked questions

How accurate is Tesseract?
Tesseract does not publish an accuracy figure. Its documentation says results depend on image quality, and independent tests show large differences between clean and noisy documents. Measure it on your own files.

Is Tesseract good enough for invoices?
It can be, on clean, upright, high-resolution printed invoices. Skew, noise and tables are known weak points, and extracting named fields such as the total needs logic on top of the raw text.

Why is Tesseract giving bad results?
Check resolution first (300 DPI or more), then skew, background and noise, then the page segmentation mode. The official documentation lists these in order of impact.

Can Tesseract read handwriting?
Its FAQ says it can try but will not work very well, because it is designed for printed text.

What is a good character error rate?
It depends on your use. For free text you read afterwards, a higher rate can be fine; for amounts and identifiers you need an exact match. Set the threshold per field before you test.

Originally published at anyformat.ai/blog/is-tesseract-accurate-enough-for-production.

Best Python OCR libraries

Felipe Cardona — Tue, 06 Oct 2026 09:15:50 +0000

The best Python OCR library depends on what your images look like. On clean, upright, high-resolution printed text, Tesseract, EasyOCR and PaddleOCR all returned essentially perfect text in our test, so the choice there is about install size and speed. They differ when the input gets harder: low resolution, rotation, noise, or two columns.

OCR, optical character recognition, turns pictures of text into text a program can use. You need it when the words you want are pixels and not characters: a scanned contract, a photo of a receipt, a screenshot, or a PDF that was made from a scan. If you can select and copy the text in your PDF, it already has a text layer and you do not need OCR at all, because a parser reads that layer directly. People run OCR to make scans searchable, to feed text to a language model, or to pull values out of invoices and forms.

This page runs the three on the same synthetic images, shows the code, and says what we did and did not measure.

What you will need

Python 3.10 or newer.
A few images of your own, ideally fictional or sample ones, because the examples print the recognised text and text from real client documents can end up in terminal and job logs. Include the ugliest ones you receive. Clean images make every library look good.
A separate virtual environment per library, because EasyOCR and PaddleOCR each bring a large framework (PyTorch and PaddlePaddle).
For Tesseract, the Tesseract program itself, not only the Python wrapper. On macOS: brew install tesseract.

pip install pytesseract pillow    # environment 1, plus the Tesseract program
pip install easyocr               # environment 2
pip install paddlepaddle paddleocr   # environment 3

Step 1. Run each library on one image

Tesseract, through its Python wrapper pytesseract:

import pytesseract
from PIL import Image

print(pytesseract.image_to_string(Image.open("scan.png"), lang="eng"))

EasyOCR, which downloads about 108 MB of models on the first call:

import easyocr

reader = easyocr.Reader(["en"], gpu=False)
print(" ".join(reader.readtext("scan.png", detail=0)))

PaddleOCR, which downloads about 133 MB on the first call. This is the 3.x API, and we switched off its three optional preprocessing modules to test the bare detection and recognition pipeline:

from paddleocr import PaddleOCR

ocr = PaddleOCR(lang="en", use_doc_orientation_classify=False,
                use_doc_unwarping=False, use_textline_orientation=False)
for r in ocr.predict("scan.png"):
    print(" ".join(r["rec_texts"]))

What we tested

We rendered 13 images with Pillow in Arial from known text: a clean paragraph at 300 DPI, the same text at 100 DPI and at 50 DPI, rotated 3 and 15 and 90 degrees, with heavy noise and blur, low contrast, in two columns, a Spanish paragraph with accents and invoice lines, two fonts that look handwritten, and a small table. We scored each output as one minus the edit distance to the true text divided by its length, so 1.0 is a perfect copy. Versions: Tesseract 5.5.3, EasyOCR 1.7.2, PaddleOCR 3.7.0.

These are easy images by construction, rendered on one Apple Silicon Mac without a GPU. Treat the scores as a way to see how each library fails, not as a benchmark.

What we saw

Image	Tesseract	EasyOCR	PaddleOCR
Clean, 300 DPI	1.000	1.000	1.000
Clean, 100 DPI	0.995	0.979	0.989
Clean, 50 DPI	0.505	0.245	0.957
Rotated 3 degrees, noise and blur	0.989	0.479	1.000
Rotated 15 degrees	0.000	0.223	1.000
Rotated 90 degrees	0.165	0.096	0.106
Heavy noise and blur	0.000	0.202	0.851
Low contrast	1.000	0.989	1.000
Two columns	0.489	0.489	0.489
Spanish and invoice lines	0.993	0.993	1.000
Small table, read as text	0.227	0.943	1.000

On clean text the choice is about weight

All three read the clean 300 DPI paragraph perfectly. Tesseract took 0.1 to 0.3 seconds per image on our machine against 1 to 5 seconds for the others, and its environment was about 36 MB against roughly 800 MB for EasyOCR and PaddleOCR, plus the Tesseract program. The first run of EasyOCR and PaddleOCR also took around 52 seconds each, because they download models.

Tesseract is sensitive to input quality

At 15 degrees of rotation and under heavy noise and blur, Tesseract returned nothing useful (0.000), and at 50 DPI it scored 0.505, while PaddleOCR scored 1.000, 0.851 and 0.957 on the same images. Tesseract's own documentation says the same thing: it works best at 300 DPI or more, and skew reduces line segmentation quality significantly. We did not try preprocessing such as deskewing or upscaling, which is exactly what its documentation recommends, so the numbers are for raw input. Tesseract also correctly reported the 90 degree rotation through its orientation detection, so a rotate step would fix that case.

EasyOCR loses reading order on noisy lines

EasyOCR scored 0.479 on the slightly rotated, blurred paragraph, mostly because it returned the line fragments in the wrong order and not because it misread them. It also scored 0.245 at 50 DPI and 0.202 under heavy noise. It had its latest release in September 2024 at the time of writing.

None of them solves layout

All three read across both columns line by line, interleaving the left and right text, so the content was complete but the order was wrong (0.489 for all three). None returns table structure, only text. Tesseract's default mode returned a single row of the table. If your job is tables or multi-column documents, these libraries give you text, not structure.

Spanish needs setup

The Homebrew build of Tesseract ships only English. With English alone it scored 0.967 on the Spanish paragraph but dropped nine accented words, among them número, Málaga and dirección, a failure that the overall score hides. Adding the Spanish language file (spa.traineddata, about 2.3 MB from the tessdata_fast repository) fixed it, with 0.993 and no missed accented words. PaddleOCR and EasyOCR missed none and one respectively.

What we did not test

We did not test real handwriting: the two fonts we used only look handwritten, so we draw no conclusion. Tesseract's FAQ says handwriting will not work very well because it is designed for printed text, and EasyOCR's README lists handwriting as a future item. We did not test real scans, preprocessing, GPU speed or non-Latin scripts.

Check on your own images

Write down the text you expect and compute the same score on your files. The function reports one number per image and never prints the text, so the output is safe to log.

def edit_distance(a: str, b: str) -> int:
    prev = list(range(len(b) + 1))
    for i, ca in enumerate(a, start=1):
        cur = [i]
        for j, cb in enumerate(b, start=1):
            cur.append(min(prev[j] + 1, cur[j - 1] + 1, prev[j - 1] + (ca != cb)))
        prev = cur
    return prev[-1]

def accuracy(expected: str, got: str) -> float:
    expected, got = " ".join(expected.split()), " ".join(got.split())
    return 1 - edit_distance(expected, got) / max(len(expected), 1)

Install and licence notes

All three are Apache 2.0 licensed. PaddleOCR 3.7.0 was released in June 2026 and EasyOCR 1.7.2 in September 2024. EasyOCR lists more than 80 languages and recommends a GPU without requiring one, and PaddleOCR's README lists more than 100 languages and support for CPU and GPU. Tesseract supports more than 100 languages and needs no GPU.

To compare these libraries with managed OCR APIs on cost, see OCR API vs open source. To test accuracy on your own files, see Is Tesseract accurate enough for production?.

When these libraries are not enough: anyformat

They return text. When you need typed fields (an invoice number, a total), structure for tables, or a confidence score you can act on, you need a layer on top: your own extraction code, or a document processing service. anyformat is one of the latter; it returns typed fields with a confidence score and the source text and page. We did not run it in this comparison, so this page makes no claim about how it scores on these images.

Frequently asked questions

What is the best Python OCR library?
It depends on the images. On clean 300 DPI printed text, Tesseract, EasyOCR and PaddleOCR were equally accurate in our test, and Tesseract was the lightest and fastest. On rotated, noisy or low-resolution images, PaddleOCR scored highest in our test without preprocessing.

Is Tesseract better than EasyOCR?
On clean text they matched. Tesseract was faster and lighter, and EasyOCR did better on the small table read as text, but lost reading order on the rotated, blurred paragraph. Neither returns table structure.

Do I need a GPU for OCR in Python?
No. We ran all three on CPU. EasyOCR says a GPU is recommended but not required, and PaddleOCR supports both. We did not measure GPU speed.

Why is Tesseract missing accents in Spanish?
The default Homebrew install includes English only. Add the Spanish language file and pass lang="spa".

Can these libraries read handwriting?
We did not test real handwriting. Tesseract's FAQ says it is designed for printed text.

Originally published at anyformat.ai/blog/best-python-ocr-library.

Extract tables from a PDF

Felipe Cardona — Tue, 06 Oct 2026 09:13:45 +0000

Extracting a table from a PDF means getting its rows and columns back as data, a list of rows or a pandas DataFrame, instead of a pile of text. It is harder than it looks, because a PDF stores characters at positions on a page and has no concept of a row or a column. A library has to infer the table from the lines drawn around the cells or from how the words line up.

You usually want this to load figures into a spreadsheet or database, to feed a table into an analysis, or to give a language model a table it can read. This page runs the three most used Python libraries on the same five fictional PDFs, shows the code that worked, and reports where each one broke.

What you will need

Python 3.10 or newer.
One PDF with a table in it, ideally a fictional or sample document, because the examples print what they find and text from real client documents can end up in terminal and job logs. Use the hardest one you have: no ruling lines, merged header cells or a table that runs across pages. A tidy ruled table makes every library look good.
One virtual environment per library, so their dependencies do not collide:

pip install pdfplumber       # environment 1
pip install camelot-py       # environment 2
pip install pymupdf          # environment 3

Step 1. Check that the PDF has a text layer

All three libraries read the text stored in the PDF. A scan is an image with no text layer, and each of them returned an empty list on our scanned test file without raising an error. Check every page first, because a text PDF can have a short cover page or a blank one:

import pdfplumber

with pdfplumber.open("table.pdf") as pdf:
    pages_without_text = [
        number
        for number, page in enumerate(pdf.pages, start=1)
        if len((page.extract_text() or "").strip()) <= 50
    ]

if pages_without_text:
    print("pages with little or no text (possible scans):", pages_without_text)
else:
    print("every page has a text layer")

A page listed there is worth a look rather than a verdict, since a cover or a blank page also has little text. If a page with a table has no text layer, none of the code below will work and you need OCR or a layout-aware parser first; see the best Python OCR libraries for the OCR options.

Step 2. Extract the table with each library

pdfplumber, the lightest of the three, reads ruled tables by default:

import pdfplumber

with pdfplumber.open("table.pdf") as pdf:
    tables = pdf.pages[0].extract_tables()

if tables:
    print(tables[0])  # a list of rows
else:
    print("no table found")

Camelot returns a pandas DataFrame, with lattice for ruled tables and stream for borderless ones:

import camelot

tables = camelot.read_pdf("table.pdf", pages="all", flavor="lattice")
print(len(tables))
if len(tables):
    print(tables[0].df)

PyMuPDF finds tables with find_tables, and the result converts to a DataFrame too:

import pymupdf

doc = pymupdf.open("table.pdf")
tabs = doc[0].find_tables()
if tabs.tables:
    print(tabs[0].extract())      # a list of rows
    df = tabs[0].to_pandas()

What we saw

We generated five fictional PDFs with a known table: one with ruling lines, one without any, one with merged header cells and a multi-line cell, one that runs across two pages with a repeated header, and one that is a scan. We compared every output cell by cell against the table we generated. The versions were pdfplumber 0.11.10, Camelot 2.0.0 and PyMuPDF 1.28.2, and each library was run in its default mode and in its text-based mode.

	pdfplumber	Camelot	PyMuPDF
Ruled table	Correct	Correct	Correct
No ruling lines, default mode	Empty	Empty	Empty
No ruling lines, text mode	Right cells plus blank rows	Right cells plus a title row	Right cells plus blank rows
Merged header, multi-line cell	Correct in default mode; broken in text mode	Correct in lattice; broken in stream	Correct in default mode; broken in text mode
Two pages	Two tables, header repeated	Two tables, header repeated	Two tables, header repeated
Scan, no text layer	Empty list, no warning	Empty list, no warning	Empty list, no warning

This is five small, clean, generated files, so it shows how each library fails and says nothing about how often it fails on your documents.

Ruling lines decide everything in the default modes

The default mode of each library is the same idea with a different name: find the lines drawn around the cells and read the text inside them. On the ruled table all three were correct. On the table with no ruling lines all three returned nothing, and on that one you have to switch to the text-based strategy, which guesses cells from word positions.

The text-based mode works but needs cleaning

With vertical_strategy and horizontal_strategy set to "text", pdfplumber found the right cells but added a blank row between every row of the table (11 rows where 6 were expected):

import pdfplumber

with pdfplumber.open("table.pdf") as pdf:
    found = pdf.pages[0].extract_tables(
        {"vertical_strategy": "text", "horizontal_strategy": "text"}
    )

rows = [r for r in found[0] if any(r)] if found else []  # drop the blank rows

After dropping empty rows the table was correct. PyMuPDF's text strategy gave the same blank rows, and Camelot's stream mode added the page title as a first row. On the table with merged header cells and a multi-line cell, the text modes broke: the cell text was split across rows and only one of five rows came out intact in pdfplumber and PyMuPDF. PyMuPDF also cut "reorder monthly" to "reorder mont" in that run.

Merged cells and page breaks are not handled for you

A merged header such as "Sales" over two sub-columns comes out as "Sales" followed by an empty cell, with the sub-headers on a second row. A table that runs across two pages comes back as two tables, each with its own copy of the header, and none of the three libraries joins them. You concatenate the pieces and drop the repeated header yourself.

A scan returns an empty list, not an error

On the scanned file every library returned an empty result without a warning, which is easy to miss in a pipeline. That is why Step 1 checks for a text layer first.

The same test on a real financial PDF

The video runs the three libraries on a real financial document from the public ParseBench dataset: two tables with 45 companies, multi-line names and merged cells. Every row was checked against the ground truth. The results shown in the video were:

Approach	Rows correct	What went wrong
pdfplumber	51.1%	Drops names in merged cells
Camelot, lattice	0%	No ruling lines to detect
Camelot, stream	88.9%	Merges the two tables
PyMuPDF	82.2%	Scrambles text in complex cells
anyformat	95.6%	43 of 45 companies

It is one document and one run each, so read it as a pattern and not as a benchmark. The pattern matches the synthetic test above: ruling lines decide the default modes, and the text-based modes keep more rows but damage them.

None of the three libraries tells you that a row is wrong. They return a table either way, so a damaged cell looks exactly like a correct one, and that is why the check below is worth writing. anyformat returns the same table with a confidence score per field and the source text each value was read from, which is what lets a person check only the doubtful rows.

Check on your own PDFs

Write down one row you know is in your table and test for it. The function reports only which check failed, never the cell contents, so its output is safe to log.

def check_table(table: list[list[str]], expected_row: list[str]) -> list[str]:
    problems = []
    if not table:
        problems.append("no table found")
    elif expected_row not in table:
        problems.append("expected row is not intact")
    return problems

print(check_table(tables[0] if tables else [], ["North", "1200", "1350", "1480"]))

Run it for each library on the same file and you have a comparison for your documents, which is worth more than ours.

Reproduce the test

The five PDFs come from a short script, so you can rerun everything. It needs pip install reportlab:

import json
from reportlab.lib.pagesizes import A4
from reportlab.platypus import Table, TableStyle, SimpleDocTemplate, Paragraph, Spacer
from reportlab.lib import colors
from reportlab.lib.styles import getSampleStyleSheet

hdr = ["Region", "Q1", "Q2", "Q3"]
rows = [["North", "1200", "1350", "1480"], ["South", "980", "1010", "1100"],
        ["East", "1500", "1620", "1710"], ["West", "760", "810", "905"],
        ["Total", "4440", "4790", "5195"]]

def simple(filename, data, grid):
    style = [("FONTSIZE", (0, 0), (-1, -1), 11), ("ALIGN", (1, 0), (-1, -1), "RIGHT"),
             ("BOTTOMPADDING", (0, 0), (-1, -1), 6), ("TOPPADDING", (0, 0), (-1, -1), 6)]
    if grid:
        style += [("GRID", (0, 0), (-1, -1), 0.8, colors.black),
                  ("BACKGROUND", (0, 0), (-1, 0), colors.lightgrey)]
    table = Table(data, colWidths=[110, 90, 90, 90])
    table.setStyle(TableStyle(style))
    SimpleDocTemplate(filename, pagesize=A4).build(
        [Paragraph("Sales by region", getSampleStyleSheet()["Heading2"]), Spacer(1, 12), table])

simple("a_ruled.pdf", [hdr] + rows, grid=True)
simple("b_borderless.pdf", [hdr] + rows, grid=False)

merged = [["Product", "Sales", "", " Notes"], ["", "H1", "H2", ""],
          ["Widget", "100", "120", "Best seller\nreorder monthly"],
          ["Gadget", "80", "95", "Discontinued\nin Q4"], ["Gizmo", "60", "70", "New"]]
table = Table(merged, colWidths=[90, 70, 70, 150])
table.setStyle(TableStyle([("GRID", (0, 0), (-1, -1), 0.8, colors.black),
                           ("SPAN", (1, 0), (2, 0)), ("SPAN", (0, 0), (0, 1)), ("SPAN", (3, 0), (3, 1)),
                           ("ALIGN", (0, 0), (-1, 1), "CENTER"), ("VALIGN", (0, 0), (-1, -1), "MIDDLE")]))
SimpleDocTemplate("c_merged.pdf", pagesize=A4).build([table])

long = [hdr] + [[f"Item{i:02d}", str(100 + i * 7), str(200 + i * 3), str(300 + i * 11)] for i in range(1, 61)]
table = Table(long, colWidths=[110, 90, 90, 90], repeatRows=1)
table.setStyle(TableStyle([("GRID", (0, 0), (-1, -1), 0.8, colors.black),
                           ("BACKGROUND", (0, 0), (-1, 0), colors.lightgrey), ("FONTSIZE", (0, 0), (-1, -1), 11)]))
SimpleDocTemplate("d_twopage.pdf", pagesize=A4).build([table])

For the scan, render the ruled PDF to an image and save it back as a PDF with no text layer:

import pymupdf

src = pymupdf.open("a_ruled.pdf")
pix = src[0].get_pixmap(dpi=150)
out = pymupdf.open()
page = out.new_page(width=pix.width, height=pix.height)
page.insert_image(page.rect, pixmap=pix)
out.save("e_scan.pdf")

Install and licence notes

Camelot is the heaviest install of the three, around 157 MB with OpenCV, against about 42 MB for pdfplumber and 53 MB for PyMuPDF in our environments. Camelot 2.0.0 no longer needs Ghostscript by default and converts pages through pypdfium2. Older 0.x versions, which most tutorials still cover, failed on every default call with "Ghostscript is not installed" in our run, even with the gs binary on the path, so install the current version.

pdfplumber is MIT licensed and Camelot is MIT licensed. PyMuPDF is dual licensed under AGPL 3.0 or a commercial license from Artifex, which matters if you ship closed-source software; read its licensing page for your case. All three had a release within the last four months on 2026-10-01.

When these libraries are not enough: anyformat

These libraries fit PDFs with a text layer and tables that are ruled or cleanly aligned. They stop fitting when tables have no lines, merged cells, multi-line cells or page breaks, or when the files are scans. For those cases people turn to a layout-aware parser, a vision language model or an OCR step that finds table structure.

anyformat's parsing is one option. Its parse result lists a document's blocks, and table blocks carry their rows, according to the SDK reference. We did not run it on the five synthetic files; in the video it ran on the real financial PDF above and got 43 of 45 companies right, which is one document and one run. For long tables specifically, see long-document extraction.

Watch the test

The video version of this test runs about five minutes and covers the three libraries and the real-PDF results above.

https://www.youtube.com/watch?v=yf3IP0Bx1oI

Frequently asked questions

What is the best Python library to extract tables from a PDF?
It depends on the table. For ruled tables in text-based PDFs all three worked in our test, and pdfplumber was the lightest to install. For tables without ruling lines, none of the defaults worked and every library needed its text-based mode plus cleanup.

Can pdfplumber extract tables from a scanned PDF?
No. It reads the text layer, and a scan has none, so it returns an empty list. You need OCR or a layout-aware parser first.

How do I get a PDF table into a pandas DataFrame?
Camelot returns one directly (tables[0].df), PyMuPDF converts with to_pandas(), and with pdfplumber you pass the list of rows to pandas.DataFrame, using the first row as the header.

Why does my table come out with blank rows?
The text-based strategies in pdfplumber and PyMuPDF find the cell edges from word positions and can add empty rows between real ones. Drop the rows where every cell is empty.

How do I extract a table that spans several pages?
Each library returns one table per page. Concatenate the tables and drop the repeated header rows yourself.

Originally published at anyformat.ai/blog/extract-tables-from-pdf.

PDF to markdown for LLMs

Felipe Cardona — Tue, 06 Oct 2026 09:12:05 +0000

Converting a PDF to markdown for an LLM means turning pages into text that keeps the structure a model needs: headings as headings, tables as tables, columns in reading order. Markdown is the usual target because models read it well, it is usually lighter than HTML, and a RAG pipeline can split it on headings instead of on arbitrary character counts.

You do this for one of three reasons: to index documents for retrieval, to paste a document into a prompt without losing its tables, or to give an agent a file it can read. Plain text extraction is not enough for any of the three, because a table flattened into one cell per line is worse than no table.

This page runs three open-source converters on the same PDFs, shows the code, and reports what came out. It also says what we did not test, which includes anyformat.

What you will need

Python 3.10 or newer and about 4 GB of free disk if you install all three, because Docling and Marker download models on first use.
One PDF of your own, ideally a sample or fictional document rather than a real client file. Use the ugliest one you have: a table, two columns, or a scan. Converters look the same on clean single-column text.
A terminal. The three open-source tools need no API keys.
One virtual environment per tool. We installed each one separately, so their dependencies do not collide:

pip install "markitdown[pdf]"   # environment 1
pip install docling             # environment 2
pip install marker-pdf          # environment 3

How we tested

We generated three fictional PDFs: a two-page report (headings, a bulleted list, a 5 by 4 table with a header row, then a page in two columns), a scan-style PDF with no text layer (a slightly rotated image of three sentences and a small table), and a 40-page document. We ran the minimal snippet from each project's README on an Apple Silicon Mac with no GPU, on 2026-09-30. The versions were MarkItDown 0.1.8, Docling 2.131.0 and Marker 2.0.0.

This is one machine and small synthetic files, each timed once. Treat it as a way to see the failure modes, not as a benchmark.

Step 1. Run the three converters

Each one is a few lines. MarkItDown, from Microsoft:

from markitdown import MarkItDown

text = MarkItDown().convert("report.pdf").text_content

Docling, from IBM Research:

from docling.document_converter import DocumentConverter

text = DocumentConverter().convert("report.pdf").document.export_to_markdown()

Marker, from Datalab. Put it under a main guard, because on multi-page PDFs it starts worker processes and, without the guard, re-runs the top of your script:

from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

if __name__ == "__main__":
    converter = PdfConverter(artifact_dict=create_model_dict())
    text, _, images = text_from_rendered(converter("report.pdf"))

What we saw

	MarkItDown	Docling	Marker
Table	Broken: one cell per line, columns mixed	Correct	Correct
Two columns	Correct order, lines hard-wrapped	Correct order, paragraphs unwrapped	Correct order, one heading dropped
Heading levels	None kept	All headings came out as `##`	`##` or `###`, levels flattened
Scanned page	Empty output	Read, table correct	Crashed without an extra install (below)
40 pages, second run	0.5 s	about 3 s	about 3.5 s
First run	none	41 s, plus 28 s to initialise	36 s, then about 7 s
Install and models	150 MB	1.1 GB plus about 570 MB of models	about 1 GB plus 418 MB of models

Times come from one Apple Silicon Mac with no GPU, single runs, on 2026-09-30.

MarkItDown is fast and only good on clean text

It converted two pages in 0.04 seconds and kept the two-column reading order. It kept no headings, turned bullet glyphs into (cid:127) lines, and scrambled the table: each cell became its own paragraph and the column order was mixed.

Region Q1 Q2 Q3
North
100
120
140
South

On the scanned PDF it returned an empty string. MarkItDown's README describes a separate markitdown-ocr plugin that sends images to an LLM with vision; we did not test it. For clean single-column text it is the cheapest option by a wide margin. For tables or scans it is not enough on its own.

Docling gave the best output here, at a cost

Docling returned the table as a correct markdown table, the list as a list and the two columns in order with paragraphs unwrapped. It also ran OCR on the scan with no configuration, returning the three sentences and a correct table. We compared by eye against the source and saw no errors; that is an observation, not an accuracy score.

| Region   |   Q1 |   Q2 |   Q3 |
|----------|------|------|------|
| North    |  100 |  120 |  140 |
| South    |  107 |  125 |  143 |

The cost is about 1.1 GB of packages and about 570 MB of models, roughly 70 seconds the first time (model download and initialisation), then a few seconds per document. It also flattened heading levels: every heading came out as ##, so a title and its subsections look the same. If your chunker splits on heading depth, that matters.

Marker: check your install before you trust it

Marker read the text PDFs, with a correct table and correct two-column order, apart from one heading it dropped on the two-column page. Two things went wrong in our run, and both are worth knowing.

First, on a Mac without a GPU, Marker 2.0.0 could not convert the scanned page. It stopped with SpawnError: llama-server binary not found. Its README says the CPU and Apple Silicon mode needs the llama-server binary from llama.cpp installed separately. We did not install it, so we have no Marker result on scans and we are not claiming one.

Second, on a 40-page PDF where every section had identical body text, Marker returned 701 characters and dropped the body of sections 2 to 40. We suspect its repeated-header removal, but we did not confirm that, so treat it as something we observed, not explained. On a 40-page PDF with unique text per section all 40 sections survived, but only 42 of 81 headings came through, with levels flattened to ### and ####.

Read the licenses before you ship any of them. Marker's README says the code is Apache 2.0 and that the model weights use "a modified AI Pubs Open Rail-M license (free for research, personal use, and startups under $5M funding/revenue)", with a commercial route beyond that through the vendor. Docling's code is MIT, and its README sends you to each model's own license. MarkItDown is MIT.

What none of them gave us

No converter here preserved true heading levels, and none returns where on the page a block came from or how sure it is of it. For a RAG chunker that is usually fine. For anything where a reviewer must see the source, or where you decide automatically what to trust, you need that information, which is what the anyformat section below describes.

Check on your own PDFs

Do not pick from our table. Write down a few things you know are in your document and test for them. It takes ten minutes and tells you more than any benchmark. The function below reports only which check failed, never the document's content, so its output is safe to log.

def check_markdown(md: str, must_contain: list[str], table_row: list[str]) -> list[str]:
    problems = []
    for i, needle in enumerate(must_contain, start=1):
        if needle not in md:
            problems.append(f"expected text #{i} is missing")
    # a table row survives if a markdown line starting with | has exactly these cells
    def is_table_row(line: str) -> bool:
        cells = [c.strip() for c in line.strip().strip("|").split("|")]
        return line.lstrip().startswith("|") and cells == table_row
    if not any(is_table_row(line) for line in md.splitlines()):
        problems.append("table row is not intact")
    return problems

print(check_markdown(text, ["Quarterly Operations Report"], ["North", "100", "120", "140"]))

Run it for each converter on the same file and you have your own comparison.

When to use which

Clean, single-column text, where speed matters more than structure: MarkItDown.
Tables, scans and multi-column layouts, if you can afford the install: Docling.
Marker, if you have a GPU or the llama.cpp dependency in place and you have read the model license. Test it on long documents first.

Another way to do it: anyformat

anyformat is a document extraction platform, and parsing is its first step, available on its own. You send a PDF and get markdown back from the API, with no models to install and no GPU.

import os
import time
from anyformat.sdk import Client
from anyformat.sdk.errors import StillParsing

client = Client(api_key=os.environ["ANYFORMAT_API_KEY"])

run = client.parse("report.pdf")
while True:
    try:
        markdown = client.get_markdown(run.id)
        break
    except StillParsing:
        time.sleep(3)

Install it with pip install anyformat. The markdown that comes back is structured: it contains anchors that identify each block of the page. The full parse result also lists those blocks with their page, bounding box and a confidence score, which is how you keep the link from a piece of text back to where it sits on the page. This example fetches only the markdown string; the block output is described in the API docs. The response shape is in the API docs. The same parse is reachable from an agent through the MCP server.

We did not run anyformat in the test above, so this page makes no claim about how its output compares on these files. Run the check from the section above on the markdown it returns and compare for yourself, using a fictional document, since real files can contain client data. If your documents are clean and you only need text for an index, a local open-source converter is the simpler choice.

Frequently asked questions

What is the best PDF to markdown converter for RAG?
It depends on your documents. On our test files Docling gave the most complete output, MarkItDown was the fastest and only reliable on clean text, and Marker needed extra setup for scans. Test on your own PDFs with a check like the one above before you pick.

Does MarkItDown do OCR?
Not for a plain PDF conversion. Its README describes a separate markitdown-ocr plugin that uses an LLM with vision to read images, and an option that uses Azure Document Intelligence.

Is Marker free for commercial use?
Its code is Apache 2.0. The model weights use a modified AI Pubs Open Rail-M license that its README describes as free for research, personal use and startups under $5M funding or revenue. Read the license in its repository for your case.

Why do tables break when converting a PDF to markdown?
A PDF stores characters at positions on a page, not rows and columns. A converter that only reads the text in order turns each cell into its own line. One that detects the table structure can rebuild the rows.

Do I need a GPU?
Not for the three tools we ran: all three converted text PDFs on a Mac without a GPU. Marker's README describes a GPU mode with higher accuracy, and its scanned-page mode on a Mac needed an extra binary, as described above.

Originally published at anyformat.ai/blog/pdf-to-markdown-for-llms.

Extract structured data from a PDF with an LLM

Felipe Cardona — Tue, 06 Oct 2026 09:10:26 +0000

Extracting structured data from a PDF with an LLM means reading the document's text, describing the fields you want as a schema, and asking the model to return values that fit that schema as JSON. It works on layouts the model has never seen, which is why it replaced per-supplier templates. It also fails in predictable ways, and most of the work in production is catching those failures.

Most people do this for one of four reasons: to build a RAG over their own documents, to load the values into a database or spreadsheet, to trigger a workflow when a document arrives (an invoice to approve, a form to route), or to give an agent facts to work with instead of pages to read. In every case the point is the same: turn a document into fields a program can use.

This page does it end to end in Python: one working script, then the five places it breaks, then what to add so you can trust the output. The example is an invoice because everyone has one, but nothing below is specific to invoices.

What you will need

Python 3.10 or newer.
An API key for the LLM you want to call. The example uses OpenAI; swap in Anthropic or Gemini if you prefer.
One PDF, ideally a fictional or sample invoice, because the examples print results and you should not send real client documents to logs or to a model you have not approved. Use the most complex one you have: a multi-page document with a table, a scan, or two columns. A clean one-page invoice makes every approach look good and hides the failures this page is about.
Five minutes to install the libraries:

pip install pymupdf pydantic openai

Step 1. Get the text out of the PDF

A PDF is a drawing instruction set, not a text file, so the first step is turning pages into text the model can read. If the PDF has a text layer, a library such as PyMuPDF reads it directly.

import pymupdf

def pdf_to_text(path: str) -> str:
    doc = pymupdf.open(path)
    pages = [f"--- page {i + 1} ---\n{page.get_text()}" for i, page in enumerate(doc)]
    return "\n".join(pages)

Keeping the page markers matters later: they let you point at where a value came from. If this returns almost nothing, the PDF is a scan and has no text layer. That is failure 1 below.

Step 2. Describe what you want as a schema

A schema is a typed description of the output: field names, types and what each field means. Declaring it forces the model to return a value of the right shape instead of writing prose.

Field	Type	Description the model reads
invoice_number	text	Invoice ID as printed, usually near the top
issued_on	date	Issue date, not the due date
supplier_name	text	Who issued the invoice
currency	text	ISO code, for example EUR or USD
purchase_order	text	Purchase order number, only if one is printed
tax	number	Total tax amount, only if shown separately
total	number	Grand total including tax
line_items	list	One entry per row in the table: description, quantity, unit price, amount before tax

The same thing written as code with Pydantic, which is what you paste into the script:

from datetime import date
from pydantic import BaseModel, Field

class LineItem(BaseModel):
    description: str
    quantity: float
    unit_price: float
    amount: float = Field(description="Line amount before tax")

class Invoice(BaseModel):
    invoice_number: str | None = Field(default=None, description="Invoice ID as printed, usually near the top")
    issued_on: date | None = Field(default=None, description="Issue date, not the due date")
    supplier_name: str | None = Field(default=None, description="Who issued the invoice")
    currency: str | None = Field(default=None, description="ISO 4217 code, e.g. EUR, USD")
    purchase_order: str | None = Field(default=None, description="Purchase order number, only if one is printed")
    line_items: list[LineItem] = Field(default_factory=list)
    tax: float | None = Field(default=None, description="Total tax amount, only if shown separately")
    total: float | None = Field(default=None, description="Grand total including tax")

The descriptions are the prompt. "Issue date, not the due date" prevents the most common mix-up on invoices, and it costs nothing. Every field is optional on purpose: if the document has no issue date or no total, the model must be able to say so instead of inventing one.

Step 3. Ask the model for JSON that fits the schema

Structured output means the model is constrained to return JSON that validates against your schema, so you get an object back, not text you have to parse. Most providers support it; OpenAI's structured outputs guide describes the OpenAI version. This example uses the OpenAI Python SDK, and the same pattern works with Anthropic or Gemini.

from openai import OpenAI

client = OpenAI()  # reads OPENAI_API_KEY from the environment

def extract_invoice(text: str) -> Invoice:
    response = client.responses.parse(
        model="gpt-5",  # use the current model id on the day you run this
        input=[
            {"role": "system", "content": (
                "Extract the invoice fields from the document. "
                "If a field is not present in the document, do not guess it."
            )},
            {"role": "user", "content": text},
        ],
        text_format=Invoice,
    )
    return response.output_parsed

The function takes the text as an argument because the next step needs the same text to check the result against.

Step 4. Check the output before you trust it

A validation step is deterministic code that tests whether the extracted values are consistent with each other and with the source. It catches the errors that look right.

def check(invoice: Invoice, source_text: str) -> list[str]:
    problems = []

    # 1. Completeness: the fields you cannot do without must be present.
    for name in ("invoice_number", "issued_on", "total"):
        if getattr(invoice, name) is None:
            problems.append(f"{name} is missing")

    # 2. Arithmetic: with tax stated, lines plus tax must equal the total, to the cent.
    #    Without it, lines can only be checked against the total as an upper bound.
    if invoice.total is not None:
        lines_sum = round(sum(li.amount for li in invoice.line_items), 2)
        if invoice.tax is not None:
            if abs(lines_sum + invoice.tax - invoice.total) > 0.01:
                problems.append("line items plus tax do not match the total")
        elif lines_sum > invoice.total + 0.01:
            problems.append("line items exceed the total")

    # 3. Grounding: every identifier the model returns must appear in the document.
    for name in ("invoice_number", "supplier_name", "purchase_order"):
        value = getattr(invoice, name)
        if value and value not in source_text:
            problems.append(f"{name} not found in source text")

    # 4. Plausibility: dates in the future are usually a misread.
    if invoice.issued_on and invoice.issued_on > date.today():
        problems.append("issued_on is in the future")

    return problems

source_text = pdf_to_text("invoice.pdf")
invoice = extract_invoice(source_text)
problems = check(invoice, source_text)

print(problems or "all checks passed")

The blocks on this page are one script: paste them into a single file in order and they run together. That is the whole pattern. This run prints the check results and not the invoice, and the walkthrough assumes a fictional invoice: with real documents, log field names and check results rather than extracted values, which can contain client data.

Here is what the checks are for. The values below are illustrative, not from a real document.

A good output

A good output passes every check. The lines add up, the number is on the page and the date is sensible:

{"invoice_number": "INV-2041", "issued_on": "2026-03-14",
 "supplier_name": "Acme Hosting S.L.", "currency": "EUR",
 "line_items": [{"description": "Hosting", "quantity": 1, "unit_price": 400.0, "amount": 400.0},
                {"description": "Support", "quantity": 2, "unit_price": 150.0, "amount": 300.0}],
 "tax": 147.0, "total": 847.0}

check() returns an empty list. The lines (700) plus the tax field (147) equal the total (847). The arithmetic check is exact only when the invoice states its tax separately. When it does not, the check can only tell that the lines exceed the total, so an under-read line goes unnoticed; that is why the other checks matter.

A bad output

A bad output looks just as tidy, and that is the danger. The model misread the table and invented a number:

{"invoice_number": "INV-2014", "issued_on": "2031-03-14",
 "supplier_name": "Acme Hosting S.L.", "currency": "EUR",
 "line_items": [{"description": "Hosting", "quantity": 1, "unit_price": 400.0, "amount": 400.0},
                {"description": "Support", "quantity": 2, "unit_price": 1500.0, "amount": 3000.0}],
 "tax": 147.0, "total": 847.0}

check() returns three problems: line items plus tax do not match the total, invoice_number is not in the source text and issued_on is in the future. Nothing in the JSON itself said any of this was wrong; only the checks did.

The grounding check is the cheap version of a large idea: a value that cannot be traced back to the page should not survive your pipeline. The longer treatment of that idea is in how to reduce LLM hallucinations in document extraction.

Where the script breaks

Failure 1: scanned PDFs

A scan has no text layer, so pdf_to_text returns almost nothing and the model is asked to extract from empty text. Detect it (less than a few hundred characters of text per page, not counting the page markers) and route the file to OCR or to a vision model that reads the page image. Never send the empty text to the LLM: it will often return plausible values anyway.

Failure 2: tables

page.get_text() flattens a table into a stream where columns and rows can interleave. A line item's quantity lands next to the wrong price and the arithmetic check in step 4 fails. Extract tables as tables (a layout-aware parser, or a vision model), or pass the model page images for the pages that contain them.

Failure 3: long documents

A 200-page contract does not fit comfortably in one prompt, and models read the middle of a long context less reliably than the start and end. Split by section or page range, extract per chunk, then merge. The merge step is where duplicates and conflicts show up, so keep the page markers. There is more on this in long-document extraction.

Failure 4: fields that are not in the document

Ask for purchase_order on an invoice without one and a model may return a plausible number instead of nothing. Make absence a legal answer: declare every field optional, as in the schema above, tell the model explicitly to return null rather than guess (the system prompt does), and let the grounding check catch the rest: it searches the document for the invoice number, the supplier and the purchase order, so an invented one is reported.

Failure 5: no way to tell right from wrong at scale

The script returns the same clean JSON whether it read the page correctly or not. If you process ten documents you can eyeball them. If you process ten thousand you need a signal per field that says which ones to review. Raw model confidence is a poor signal, because it tends to be highest where the model is filling a gap. This is the problem the next section is about.

What to add for production

Three things separate a script from a pipeline: a pointer from each value back to where it was read, a confidence score you can set a threshold on, and a place where a person reviews what falls below it. You can build all three on top of the code above. The grounding check is a start, a calibration set and a threshold come next, and a review interface is the largest piece.

Another way to do it: anyformat

anyformat is a document extraction platform, and the script above is the job it does for you. The steps are the same (parse the document, apply a schema, return fields), but the pointer to the source, the confidence score and the review interface are already built.

The workflow is defined once as a typed graph, a parse node feeding an extract node, then each document is one upload and one poll. Each field comes back with its value, a confidence score and the evidence it was read from.

import os
from anyformat.sdk import Client
from anyformat.workflow import Schema

client = Client(api_key=os.environ["ANYFORMAT_API_KEY"])

result = (
    client.workflow("Invoice")
    .parse()
    .extract([
        Schema.string("invoice_number", "Invoice ID as printed, usually near the top."),
        Schema.date("issued_on", "Issue date, not the due date."),
        Schema.float("total", "Grand total including tax."),
    ])
    .create()
    .run("invoice.pdf")
    .wait()
)

field = result.fields["total"]
print(field.value, field.confidence)  # value is a string; confidence runs from 0 to 100
for e in field.evidence:
    print(e.page_number, e.text)

Install it with pip install anyformat. As above, use a fictional document while you try it: the example prints a value and its evidence, and real documents can contain client data. A field the model could not find comes back as null, with a low confidence score so you can filter it. The evidence is the source text and the page number, so a reviewer checks a flagged field against the page in seconds. The response shape and the full node list are in the API docs. The reasoning behind per-field confidence is in calibrated confidence, and the same workflow is reachable from an agent through the MCP server.

anyformat is one option among several. If you process a few dozen documents of one type, the script above plus the checks in step 4 is enough, and you should not pay for more. The case for a platform starts when volume, variety or the cost of a wrong value makes the review layer the real project.

Frequently asked questions

Can an LLM extract data from a PDF directly?
Yes, if you give it the PDF's text or page images and a schema for the output. The hard part is not the extraction call. It is handling scans, tables and long documents, and knowing which of the returned values to trust.

What is the difference between structured output and JSON mode?
JSON mode guarantees the reply is valid JSON. Structured output guarantees it also matches your schema: the field names, the types and the required fields. For extraction you want the second.

How do I stop an LLM from making up values in extraction?
You cannot bring it to zero, so make it detectable: declare fields optional, instruct the model to return null instead of guessing, verify that each value appears in the source, and validate values against each other. More on this in reducing hallucinations in document extraction.

Does this work on scanned PDFs?
Not with a text library alone. A scan has no text layer, so you need OCR or a vision model first. Detect the empty text layer and route accordingly.

How much does LLM extraction cost per page?
It depends on the model, the page length and whether you send text or images. Measure it on 20 of your own documents before you pick a model, because public price lists change often enough that any number here would go stale.

Originally published at anyformat.ai/blog/extract-structured-data-from-pdf-with-llm.