Tables, not text dumps

PDF Parsing Tool and Software: PDF Parser to Excel, CSV and API

Upload a PDF and get every table back as rows and columns, with amounts stored as numbers and scanned pages read by OCR. No template to draw, no model to train, no per-row formatting charge. The same parser runs behind a REST API when the output needs to land in your own system instead of a workbook.

Built for finance, operations and data teams parsing invoices, statements, reports and price lists every week.

Uploading your PDF…

Drop your PDF here or click to browse

PDF files up to 50MB

Parse one of your own documents and check the rows before you choose a plan.

The short answer

PDF parsing tools fall into four groups: open source libraries such as pdfplumber and Camelot, template parsers that read fixed zones of one layout, AI field extractors that return named values through billed workflows, and table-first parsers that return every row of every table. Pick by the output you need and the billing unit you can live with. If the job is turning business PDFs into Excel or CSV, a table-first parser on a per-file plan is usually the cheapest to run and the quickest to set up, because it needs no template per sender and does not charge again for each row it formats.

4 types

Of PDF parser, each with a different output and a different meter

Per file

How our plans count, so long documents cost the same as short ones

OCR included

Scanned pages are read on every plan with no second model to license

XLSX, CSV, JSON

The same parse downloads as a workbook or arrives over the API

The four kinds of PDF parsing software, and what each one hands back

Search for a PDF parser and you get a Python library, a malware analysis script, an enterprise document platform and an online converter on the same results page. They are not competing for the same job. The useful question is what shape of data you want at the end, because that decides the category before price ever comes into it.

Type one

Open source libraries

pdfplumber, Camelot, Tabula, PyMuPDF and pypdf. No license fee, full control, and a real option for an engineering team with clean digital PDFs. The cost moves into tuning: table settings per layout, stitching tables that cross a page break, and a separate OCR stage for scans, because a library reading the text layer returns nothing from an image.

Type two

Template or zonal parsers

You draw rules or zones on a sample document and the parser reads the same coordinates on every file after it. Excellent when one sender sends one layout forever. Every new vendor means a new template, and a layout change on the sender side quietly breaks extraction until someone notices blank cells.

Type three

AI field extractors and workflow platforms

Nanonets, Docsumo, Rossum and the AI modes of Parseur return named fields such as vendor, invoice number and total, then route them through approvals and exports. Strong for accounts payable at scale. The billing follows the workflow, so extraction, formatting, lookups and exports are each metered, and the bill grows with steps as well as volume.

Type four

Table-first parsers

Detect every table on every page and return the rows with columns intact, scans included. Nothing to configure per sender, and the output is the spreadsheet itself. This is what PDFxlsx is. It is the right tool when the data you need lives in grids: line items, transactions, schedules, price lists, ledgers.

PDF parser comparison: output, scans, new layouts and the billing unit

Vendor billing units are taken from each vendor's own published pricing and billing documentation. The row for us is where we win and where we do not, stated plainly.

Parser type What you get back Scanned PDFs A new sender layout Billing unit Best for
Open source library Text, word positions, tables you tune for Needs a separate OCR stage Often needs new settings No license, engineering time Developers with clean digital PDFs
Template parser Fields from zones you drew Varies by vendor New template each time Per page or per document A few stable layouts at volume
AI workflow platform Named fields, routed and exported Yes Usually handled, sometimes retrained Per page, per step, often per row AP teams wiring approvals into an ERP
PDFxlsx, table-first Every table as rows in XLSX, CSV or JSON Yes, OCR on every plan Nothing to set up Per file, flat monthly plan Teams who need the grid itself. Not a fit if you want only named header fields pushed straight into an ERP.

How much does PDF parsing software cost? Check the unit before the price

Two parsers can advertise similar headline prices and send very different invoices, because they count different things. Three meters show up again and again, and each one is expensive for a different kind of document.

Per page: long documents get expensive

Parseur charges one credit for each PDF page, and its own FAQ notes that an email or a CSV costs one credit however long it is. So the same data costs more when it arrives as a PDF, and a 30 page supplier statement costs thirty times a one page invoice. Plans start at $49 a month for 100 pages. The full ladder is in our breakdown of Parseur pricing.

Per step and per row: big tables get expensive

Nanonets documentation prices data extraction at 0.30 credits per page, and counts formatting runs per table row: formatting two columns on a ten row table is twenty runs at 0.02 each. That is fine on a short invoice. On a twelve page statement with 360 transactions, formatting the date and amount columns is 720 runs, or 14.40 credits, which is four times the 3.60 credits the extraction itself cost. The worked numbers are in Nanonets pricing.

Per file: page count and row count stop mattering

Our plans count conversions. Starter is $9 a month for 50 files, Plus is $24 a month for 500 files with batch upload and team column mapping, and Pro is $49 a month for unlimited files plus the API. A four hundred page report and a single page invoice are one conversion each, and cleaning the columns with a saved mapping template does not add a charge. See the full pricing page for yearly billing.

How our PDF parser turns a document into rows

1

Upload or POST

Drop a PDF into the tool above, upload a batch of up to 20 files on Plus and Pro, or send the file to the REST API with a bearer token.

2

Read every page

Digital pages are read from the text layer. Pages without one go through OCR automatically, so mixed files with a scanned appendix still come back whole.

3

Detect the tables

Each grid is found and its columns are inferred from alignment, including borderless tables and ones with an empty cell that would otherwise shift the row left.

4

Export the result

Download XLSX or CSV, or read the tables as JSON from the status endpoint. The API response also reports pages, tables and rows found, which is worth asserting on.

Why is PDF parsing hard? The five places parsers break

A PDF has no rows. It has characters placed at coordinates, and every parser is guessing the grid back from the spacing. Independent testing agrees that no single approach wins everywhere: a 2024 comparative study of ten open source parsing tools across six document categories found the best table detector changed by category, with Table Transformer strongest on financial documents and Camelot strongest on tenders.

What that means in practice is that you should test a parser on your own worst document, not on the vendor's sample. The failures below are the ones worth looking for.

Borderless tables

No ruling lines, so column boundaries come from whitespace alone. Text extractors collapse these into one column. See why a PDF converts to Excel in one column.

Wrapped cells

A two line description becomes two rows, and forty line items arrive as ninety.

Tables that cross pages

Repeated headers and carried-forward subtotals land inside the data and double a column total.

Scans with no text layer

A library returns an empty result, not an error. Our OCR PDF to Excel path handles these on the same upload.

Numbers stored as text

Currency symbols, thousands separators and (125.00) negatives that will not sum until someone cleans them.

Who uses a table-first PDF parser

Accounts payable and bookkeeping

Line items from vendor invoices, aging reports and statements of account, parsed into a sheet you can tie out against the printed total. Start with converting invoice PDFs to Excel.

FP&A and audit

Trial balances, general ledgers and financial reports that arrive as PDFs from clients or subsidiaries. PDF to Excel for finance teams covers the close-week workflow.

Procurement and operations

Supplier price lists and purchase orders compared line by line. The price-list case is on converting a price list PDF to Excel.

If you are a developer weighing this against building on a library, the endpoint details are on the PDF to Excel API page, and the PDF table extractor shows the table detection on its own.

Which PDF parsing tool should you choose?

Choose something other than us when

  • You need a handful of named header fields routed through approvals and posted into SAP or NetSuite. An AI workflow platform is built for that.
  • You receive one layout from one sender, forever, at very high volume. A template parser will be cheap and predictable.
  • You have engineers, clean digital PDFs, and a reason to keep the parsing code in house. Start with pdfplumber or Camelot.

Choose PDFxlsx when

  • The data you need is the table itself, every row, not three fields pulled from it.
  • Layouts vary from sender to sender and nobody has time to draw templates.
  • Documents are long or table heavy, so per-page and per-row meters are what make other tools expensive.
  • You want to start parsing today and move to the API later without switching engines.

PDF parsing software: common questions

It depends on what you need back. For every row of every table in Excel or CSV, a table-first parser is the fastest route. For a few named fields from one stable layout, a template parser is cheaper. For a developer building a pipeline on clean digital PDFs, an open source library such as pdfplumber or Camelot costs nothing but engineering time. No single tool wins every document type.

PDF parsing software reads the content of a PDF and returns it as structured data instead of a picture of a page. Good parsers find where tables start and stop, keep each value in its column, read scanned pages with OCR, and hand back rows you can load into Excel, a database or an accounting system without retyping.

Because a PDF stores positioned characters, not tables. There is no row or column in the file, only text drawn at coordinates, so a parser has to infer structure from spacing and lines. Borderless tables, wrapped cells, tables that run across pages, headers repeated mid-table and scans with no text layer at all are where most parsers go wrong.

OCR turns an image of text into characters. Parsing turns characters into structure. A scanned invoice needs both: OCR to read the words, then parsing to decide which words form the line-item table and which column each amount belongs in. A digital PDF already has a text layer and needs parsing only, which is why OCR alone never gives you a usable spreadsheet.

Yes, if it is built for tables. Table-first parsers detect each grid, keep rows and columns aligned, and export an XLSX where amounts are numbers rather than text. Field extractors return a list of named values instead, and plain text extractors return lines with the columns collapsed, so check the output format before you commit to a tool.

Yes. Most commercial parsers expose a REST API. The usual pattern is a POST with the file, an identifier back, then a status call that returns the parsed tables once processing is done. Ours works that way on the Pro plan and returns tables as JSON plus links to XLSX and CSV downloads, so the same parse feeds a system and a spreadsheet.

Pricing units differ more than the prices do. Parseur bills one credit per PDF page from $49 a month for 100 pages. Nanonets bills every workflow step, with AI extraction at 0.30 credits per page and formatting charged per table row. Open source libraries have no license fee. Our plans are flat per file, from $9 a month for 50 conversions.

Only with a parser that runs OCR first. A scan is an image, so a library that reads the text layer returns nothing at all. OCR is included on every one of our plans and runs automatically when a page has no text layer, so a scanned supplier statement and a digital one go through the same upload with no separate model to pay for.

Parse your hardest PDF first

Pick the document that broke the last tool you tried, a borderless statement or a scanned invoice, and run it through the parser at the top of this page. If the rows come back right, the PDF to Excel converter and the API use the same engine.