PDF to Excel API: Convert PDF to Excel and CSV, With OCR, Over a REST API
Three HTTP calls, no SDK to install. POST a PDF, poll one status endpoint, download clean XLSX or CSV, or read the tables straight back as JSON. The same extraction engine that runs the web app, behind a bearer token, priced as a flat monthly plan instead of a per page transaction meter.
Included with the Pro plan. Unlimited conversions, OCR on scans included, files up to 50MB. Try the engine on a real document first, right here.
Drop your PDF here or click to browse
PDF files up to 50MB
Test the engine in the browser before you write a line of code.
The short answer
To convert a PDF to Excel from code, POST the file as multipart form data to /api/v1/conversions with a bearer token, read the job id from the 202 response, poll /api/v1/conversions/{id} until the status is done, then GET the download route for xlsx or csv. The conversion is asynchronous on purpose, because OCR on a long scanned document takes longer than an HTTP request should live. The decision that costs the most money is not which SDK you pick, it is the billing model: transaction meters that count one unit per five pages turn a 200 page report into 40 billable units, while a flat plan does not move with page count at all.
Last updated September 2026
3 Calls
Upload, poll, download
No SDK
Plain REST and JSON
XLSX, CSV, JSON
Three output paths
Flat $49
Per month, unlimited
Convert a PDF to Excel programmatically in three calls
Mint a token in your dashboard, then send it as a bearer header on every request. There is nothing else to configure.
Upload the PDF
POST the file as multipart form data on the field named file. You get 202 back straight away with a job id, not a finished spreadsheet.
curl -X POST \
https://pdfxlsx.com/api/v1/conversions \
-H "Authorization: Bearer $TOKEN" \
-H "Accept: application/json" \
-F "file=@report.pdf"Poll until it is done
Read status until it reads done. The same response carries page, table and row counts, and the parsed tables as JSON.
curl https://pdfxlsx.com/api/v1/conversions/123 \
-H "Authorization: Bearer $TOKEN" \
-H "Accept: application/json"Download the spreadsheet
Hit the download route for xlsx or csv. Or skip this entirely and use the JSON tables from step two.
curl -OJ \
https://pdfxlsx.com/api/v1/conversions/123/download/xlsx \
-H "Authorization: Bearer $TOKEN"That is the whole integration. If you are wiring this into a nightly job that picks up a folder of documents, the same engine also runs batch conversion in the web app, which is often the faster way to prove the output is right before you automate it. Teams who want the workflow without writing code usually start with automated PDF to Excel conversion instead.
Endpoint reference
Three routes, all under the same bearer token. Every response is JSON except the two download routes, which return a file.
| Method and path | What it does | Success response |
|---|---|---|
| POST /api/v1/conversions | Uploads a PDF on the multipart field file and queues the conversion. |
202 with id, status and download links |
| GET /api/v1/conversions/{id} | Reports job status, counts, and the parsed tables once processing finishes. | 200 with status, counts, tables when done |
| GET /api/v1/conversions/{id}/download/{format} | Streams the finished spreadsheet. Format is xlsx or csv. | 200 with the file as an attachment |
Fields on the status response
status
pending, processing, done or failed. Branch on this before you read anything else, because an empty tables array on a done job is a genuine answer and a failure is not.
engine
Which extraction path handled the file. Log it and you will know what share of your real volume is scanned rather than digital, which is usually higher than teams expect.
pages_count
Pages in the source document. Useful as a sanity check, and useful for costing the same volume against any competitor that meters by page.
tables_count and rows_count
How much structure came out. The cheapest automated quality gate is asserting that rows_count is within a few percent of what you expect for that document type.
tables
The parsed tables as JSON, present only when the status is done. This is the path to take when the destination is a database and you never want a file on disk.
error
Present only on a failed job, with the reason. Route these to a retry queue or to a human rather than letting them land silently as empty output.
The thing that decides the bill is the billing unit, not the rate
Every document API quotes a headline number and then defines a unit underneath it. Those units are not comparable, and the difference between them is frequently larger than the difference between the rates. Price the same real workload through each model before you sign anything.
| Billing model | How a unit is counted | Where it hurts | Who it suits |
|---|---|---|---|
| Transaction per few pages | One unit per block of pages, rounded up per document. Extraction endpoints often use a five page block where other operations use fifty. | Long documents. A 200 page report is 40 units, and a one page invoice still costs a whole unit. | Low volume of short, uniform files |
| Monthly page quota | A pool of pages per month, drawn down one page at a time, usually with no rollover. | Lumpy months. Quarter end burns the pool and the unused pages from a quiet month are gone. | Predictable, steady page volume |
| Document credits | One credit per document, sometimes capped at a page count above which a second credit is spent. | Many short files. A mailbox of one page notes spends a full credit each. | Fewer, longer documents |
| Quote only, annual commit | No published price. A sales conversation, a written agreement, and frequently a large annual minimum. | Small teams. You cannot budget or prototype without a call, and the entry point can be far above your volume. | Enterprise procurement |
| Flat plan, this API | $49 a month on the Pro plan, unlimited conversions, files up to 50MB each. | Very low volume. If you convert five documents a month, a metered plan is cheaper. | Steady or spiky volume of long documents |
The arithmetic worth doing before a purchase order takes about two minutes. Take one real month of documents, count the pages, then run that number through each vendor's unit definition rather than through their headline rate. We keep dated, first party breakdowns of what the major document APIs actually charge, including Adobe PDF Services API pricing, Amazon Textract pricing, Azure Document Intelligence pricing and Google Cloud Vision API pricing. The market pricing table puts the whole field side by side.
Who ships against this API
Almost always somebody who already has the documents arriving automatically and needs the data in a system, not in a download folder.
Product teams adding import
Your users want to upload a PDF statement or report into your app. Building table extraction in house is months of work for a feature that is not your product.
Internal automation and RPA
A scheduled job pulls documents from a mailbox or SFTP drop and needs rows in a warehouse by morning. See data entry automation.
Data and analytics engineers
The source system only exports PDF, and the pipeline needs typed columns rather than a text blob. The JSON tables path skips the spreadsheet step entirely.
Accounting and finance ops
Hundreds of statements or invoices a month on a close deadline. Start with the bank statement converter or the invoice converter to check output quality first.
The sensible order is to prove the extraction on your own worst document before you write any integration code. Drop a real file into the converter at the top of this page, or run a representative sample through the PDF table extractor and the OCR PDF to Excel converter if your volume is scanned. Very long files behave the same through the API as they do in large PDF conversion, and if CSV is your destination format the PDF to CSV converter shows exactly what the download route returns.
Errors you should handle
403 plan_required
The token is valid but the account is not on Pro. API access is a paid plan feature, so this is the response a free account gets, as JSON rather than a redirect to a login page.
403 on someone else's job
Every read checks ownership of the conversion, not just the validity of the token. Guessing a job id gets you nothing.
409 not ready
You hit a download route before the job finished. Poll the status endpoint first rather than retrying the download in a tight loop.
422 validation
The upload is not a PDF or is over the size limit. File type is checked by reading the file contents, not the extension, so renaming a scan to .pdf will not get it through.
Three things worth building in on day one
Back off your polling
A short scanned document and a 300 page report are not on the same clock. Poll every couple of seconds at first and widen the interval, rather than hammering a fixed one second loop for a job that takes a minute.
Assert on rows_count
A silent quality regression looks like a successful job with a third of the usual rows. Comparing rows_count against an expected range per document type catches it before the data reaches a report.
Store the source file id
When somebody questions a number six weeks later, the first question is which PDF it came from. Keep the conversion id next to the loaded rows and the audit trail costs nothing.
Check the output before you automate
Column alignment is where converted tables go wrong, and it goes wrong quietly. There is a full checklist in how to check a PDF to Excel conversion for errors.
PDF to Excel API: common questions
Yes. pdfxlsx exposes a REST API on the Pro plan: POST a PDF to /api/v1/conversions, poll /api/v1/conversions/{id} until the status is done, then download the result as XLSX or CSV. Authentication is a bearer token you mint in your dashboard. The API runs the same extraction engine as the web app, so results match what you see in the browser.
Send the PDF as multipart form data to the conversion endpoint and read the job id from the 202 response. Poll the status endpoint on an interval, or handle it in a background worker, and download the spreadsheet once the status flips to done. It is three HTTP calls in total and needs no SDK, which is why a plain curl or requests script is enough to ship it.
Here it is included in the Pro plan at $49 a month with unlimited conversions, so the cost does not move with page count. Most document APIs bill per transaction instead, and several count one transaction per five pages, which makes a long report cost several times what the price sheet implies. Compare the two models on total pages, not on the headline rate.
Yes. OCR runs automatically when a page carries no extractable text layer, so scans and photographed documents go through the same endpoint as digital PDFs. You do not set a flag or call a different route. The response reports which engine handled the file, so you can log that field and see how much of your volume is actually scanned.
XLSX and CSV as downloadable files, plus the parsed tables as JSON on the status endpoint. The JSON path matters when you are loading straight into a database or a queue and never want a file on disk. Numbers come back as numbers rather than strings, which is the part that usually breaks a naive text extraction pipeline.
No. The API is plain REST with multipart upload and bearer token auth, so anything that can make an HTTP request works: curl, Python requests, Node fetch, PHP Guzzle, Postman, or a no code tool like Make or Zapier with a webhook step. There are three endpoints and no client library to keep in sync with a version.
Asynchronous. The upload returns 202 immediately with a job id, and the conversion runs on a queue. That is deliberate: a 300 page scanned document takes real time to OCR, and a synchronous call would either time out at your load balancer or force an artificially small page limit. Poll the status endpoint or check it from a worker.
Files up to 50MB, the same ceiling as the web app. Long documents are processed page by page and stitched back together, so a multi hundred page report comes back as one continuous table rather than one table per page. If you are pushing files past that size, split them by section before upload.
The status endpoint returns a status of failed together with an error message, rather than an empty result that looks like a document with no tables. That distinction matters in a pipeline: an empty table array from a successful job is a real answer, and a failure is something to retry or route to a human. Check status before you read the tables field.
Tokens are scoped to your account and every read checks ownership, so a token can only reach conversions it created. Files are encrypted in transit and at rest, processed in an isolated environment, and deleted after conversion completes. Nothing is retained for training an outside model. If you are handling client statements under an engagement letter, that is the property that matters.
Related converters
AI PDF to Excel Converter: Convert PDF to Excel With AI Accuracy
Convert PDF to Excel with an AI converter that reads tables and scanned files, keeps numbers numeric, and exports clean XLSX or CSV.
FeaturesPDF to XLSX Converter: Convert PDF to XLSX Online
PDF to XLSX converter that writes a native Excel file with real cell structure: numbers numeric, dates as dates, tables aligned. OCR included.
FeaturesPDF Table Extractor: Extract Tables From PDF to Excel
Extract tables from PDF to Excel automatically. A PDF table extractor that keeps rows and columns aligned, handles merged and multi-page tables, and reads scans.
FeaturesOCR PDF to Excel: Convert Scanned and Image PDFs to Excel
OCR PDF to Excel converter for scanned and image-based PDFs. Turn photos, scans, and image PDFs into editable Excel with numbers kept numeric, not retyped.
Test the engine, then ship the integration
Convert a real document at the top of this page to see the output quality, then mint a token on the Pro plan and wire up the three calls. For everyday work in the browser rather than in code, start with the PDF to Excel converter.