How to Convert a PDF to JSON

Last updated July 2026.

To convert a PDF to JSON, pick the method that matches the PDF. For a digital PDF with a real text layer, an open-source library like pdfplumber or PyMuPDF reads the text for free, and you map it into JSON yourself. For a scanned PDF, the page is an image, so you need OCR: send it to a document extraction API that runs the OCR and returns the values as structured JSON. For named fields and tables rather than loose text, a document extraction API is the reliable path in any language, because it returns the fields already structured instead of leaving you to parse layout by hand.

A PDF is a layout format. It was built to look the same on every screen and printer, which means the data inside it is pinned to page coordinates rather than stored as records. JSON is the opposite: a lightweight, machine-readable structure that databases, APIs and code read natively. Converting one to the other is really about recovering the data from the layout and giving it a shape software can query. How hard that is depends entirely on one thing: whether the PDF has a real text layer or is a scan.

How do I know if my PDF is digital or scanned?

Open the PDF and try to select the text with your cursor. If you can highlight and copy words, it is a digital PDF with a real text layer, exported from software like Word, an accounting system or a browser. If the whole page selects as one block or nothing selects at all, it is a scan: a photograph of a page saved inside a PDF wrapper. This matters because a digital PDF can be read by a text parser, while a scan has no text to read until OCR turns the pixels back into characters. Many real-world files are mixed, so a method that handles both without you checking first saves work.

Method 1: convert a digital PDF to JSON with a library

If the PDF is digital and you only need it once, a library is the cheapest route. In Python, pdfplumber and PyMuPDF both read the embedded text and its position on the page. You then write code that finds the values you care about and assembles a dictionary, which json.dumps turns into JSON.

import pdfplumber, json

with pdfplumber.open("statement.pdf") as pdf:
    text = pdf.pages[0].extract_text()

# you write the parsing: find the fields in the text
data = {"account": "...", "balance": "..."}
print(json.dumps(data, indent=2))

The catch is in that comment. The library hands you text and coordinates, not fields. You write the logic that turns "Account 1234 Balance $5,102.30" into a clean object, and you rewrite it whenever the layout changes. For one file with a fixed layout that is fine. For scans it does nothing, because there is no text layer to read.

Method 2: convert a scanned PDF to JSON with an OCR API

A scanned PDF needs OCR before there is any text to structure. Optical character recognition reads the page image and recovers the words, and a document OCR API returns them as JSON in one request. This is also the right call for volume or mixed layouts, where writing a parser per document type does not scale. The pattern is three HTTPS calls: upload the file, start extraction, read the JSON. Here it is in Python against a PDF to JSON API.

import requests, time

headers = {"Authorization": "Bearer YOUR_API_KEY"}
base = "https://docuocr.com/api/documents"

with open("scan.pdf", "rb") as f:
    file_id = requests.post(f"{base}/upload", headers=headers,
                            files={"file": f}).json()["file_id"]

job = requests.post(f"{base}/extract", headers=headers,
                    json={"file_id": file_id}).json()["extraction_hash"]

while True:
    res = requests.get(f"{base}/extraction/{job}", headers=headers).json()
    if res["status"] == "completed":
        break
    time.sleep(2)

fields = res["fields"]   # structured JSON, ready to store

The same endpoint reads a digital PDF too, so your code does not branch on the file type. That is the practical advantage of the API path: one integration handles the whole mixed pile of documents, and a scan is no harder than an export.

Method 3: get named fields and tables, not just text

Raw OCR gives you the words. It does not tell you which word is the invoice number and which is the total. There is a real difference between OCR and structured extraction, and it decides how much code you write after the response. A raw OCR API such as Google Cloud Vision returns text and bounding boxes, so you still map coordinates to fields. AWS Textract returns a Blocks array of geometry and relationships that you assemble yourself. A document extraction API returns named fields and table rows already: invoice_number, invoice_date, a totals object, and each line item as a row with cells in order. It also returns a confidence score on every value, so you can auto-accept high-confidence data and route anything uncertain to a person.

What does the JSON look like?

A good structured response separates fields from tables and carries confidence, so downstream code can trust it. A trimmed example from an invoice:

{
  "fields": [
    {"name": "invoice_number", "value": "INV-4821", "confidence": 0.99},
    {"name": "total", "value": "1250.00", "confidence": 0.97}
  ],
  "tables": [
    {"rows": [["Design work", "10", "100.00"], ["Hosting", "1", "250.00"]]}
  ]
}

Because the shape is predictable, you deserialize it into a class or record and write it straight to a database, a message queue, or an accounting workflow. That predictability is the whole point of converting to JSON: the data stops being locked to a page and becomes something your software can act on.

Which method should I use?

Use a library when the PDF is digital, the layout is fixed, and you need it once or twice. Use an OCR API when documents are scanned, high-volume, or arrive in layouts you do not control. Use a document extraction API when you want named fields and tables without maintaining a parser, or when confidence scoring matters because wrong data has a cost. Most teams that start with a library move to an API the first time a scan or a new layout breaks the parser, because rewriting extraction rules is the expensive part, not the JSON.

PDFs are one source of locked-up data, but not the only one. If the records you need live on web pages rather than in files, a web scraping API that turns any site into clean, structured data solves the same problem from a different input. The principle is identical: get the values out of a format built for humans and into one built for software.

Convert your PDFs to JSON

If your documents are scanned, mixed, or high-volume, the PDF to JSON API handles native and scanned PDFs through one endpoint and returns named fields, tables and confidence as JSON. You can test it on your own files with the free tier before writing a single line of parsing. Developers can start from the Python OCR API guide or the document OCR API reference.