How to Get JSON Output From OCR
Jul 11, 2026 • 6 min read
Raw OCR returns text, not JSON. Here is how to get structured JSON from a scanned document: what raw OCR gives you, what a document extraction API adds, and how to keep the output reliable.
// Try it now
PDF, JPG, PNG, BMP, HEIC, TIFF
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Uploading...
Last updated July 2026.
To get JSON output from OCR, use a document extraction API rather than a raw OCR engine. Raw OCR reads a scanned page and returns text plus the coordinates of each word, which is not structured data. A document extraction API runs the same OCR and then organizes the result into JSON: named fields like invoice_number and total, tables as ordered rows, and a confidence score on every value. You POST the image or scanned PDF, and you read back a JSON object your code deserializes directly, with no coordinate math to write yourself.
OCR and JSON solve different halves of the same problem. OCR, optical character recognition, turns a picture of text into characters. JSON is how software stores and moves structured records. Between them sits the hard part: deciding which recovered characters are the account number, which are the date, and which belong in a table. Whether you get that for free depends on which kind of OCR you call.
Why does raw OCR not return JSON?
Raw OCR is built to recognize characters, not to understand documents. Google Cloud Vision, for example, returns the full text of a page and a bounding box for every word, and that is genuinely useful if all you want is the words. But it does not know that the number in the top right is an invoice number, because that requires understanding the document's meaning, not just its pixels. So the JSON you get from raw OCR is a flat list of text and geometry. Turning it into fields means writing rules that map positions to meaning, and rewriting them when the layout changes.
How do I get structured JSON from a scanned document?
Send it to a document extraction API, which pairs OCR with a layer that identifies fields and tables. The call pattern is three steps: upload the file, start extraction, and read the JSON. Because the recognition and the structuring happen server-side, your code only deals with the finished object.
import requests, time
headers = {"Authorization": "Bearer YOUR_API_KEY"}
base = "https://docuocr.com/api/documents"
with open("receipt.jpg", "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)
print(res["fields"], res["tables"])
This works the same for a photo, a scanned PDF or a screenshot, because they are all images to the OCR layer. You can see the same idea in the PDF to JSON API, which returns the identical JSON shape whether the PDF is a scan or a digital export.
What should the OCR JSON contain?
Three things separate JSON you can build on from JSON you have to babysit: named fields, structured tables, and confidence. Named fields mean the response labels each value, so you read res["fields"] instead of guessing from position. Structured tables mean line items come back as rows with cells in order, so a five-line invoice is five rows, not a wall of text. Confidence means each value carries a score from the OCR and extraction, so you can set a threshold. A trimmed example:
{
"fields": [
{"name": "merchant", "value": "Acme Supply", "confidence": 0.98},
{"name": "total", "value": "84.20", "confidence": 0.91}
],
"tables": [{"rows": [["Paper", "2", "40.00"], ["Toner", "1", "44.20"]]}]
}
How do I keep OCR JSON reliable?
Use the confidence scores instead of trusting every value. The realistic accuracy of OCR on a clear scan runs in the high 90s, but the failures are not evenly spread: a smudged digit or a tight column is where errors hide. A production pipeline reads the confidence on each field, auto-accepts anything above a threshold you set (say 0.95), and routes lower-confidence values to a person to confirm. That turns OCR from a system you have to spot-check into one you can run at volume, because the uncertain cases flag themselves. Blindly trusting raw text is what causes silent errors downstream.
Which OCR services return JSON, and what kind?
Almost every OCR service returns JSON, but the JSON means very different things. The useful distinction is whether it carries named fields or only text and geometry.
| Service | JSON you get back |
|---|---|
| Google Cloud Vision | Full text plus a bounding box per word. No named fields. |
| AWS Textract | A Blocks array of geometry and relationships you assemble into fields. |
| Azure AI Document Intelligence | Layout, and named fields for its prebuilt models (invoice, receipt, ID). |
| Google Document AI | Text plus entities, once you configure a processor or schema. |
| Document extraction API (DocuOCR) | Named fields, table rows and a confidence score, from one call. |
The pattern is clear: raw OCR services return text-shaped JSON and leave the mapping to you, while prebuilt-model and extraction services return field-shaped JSON. If your documents match a provider's prebuilt model, you get structure for free; if they do not, you either train a custom model or use an extraction API that reads arbitrary layouts. The wrong assumption to make is that "returns JSON" means "returns your fields." Read a sample response before you commit, and check whether the values you need are labeled.
How do I handle multi-page and batch OCR to JSON?
Two things change at volume. First, multi-page documents: a good API returns page numbers on each value or a per-page array, so a ten-page statement stays organized rather than collapsing into one blob. Second, throughput: instead of a tight loop that trips rate limits, push documents through a queue and register a webhook so each result is delivered as its job finishes. That keeps you under the per-second cap and means you are not holding a connection open while a large scan is processed. For thousands of documents a day, the webhook pattern is the difference between a pipeline that keeps up and one that backs up.
What do I do with the JSON next?
Because the output is structured, it drops straight into whatever comes next: a database insert, a message on a queue, a POST to an ERP or accounting system. This is where OCR stops being a document tool and becomes part of a data pipeline. Many teams pipe the JSON into the systems they already run, so the extracted values flow between apps without anyone retyping them; a platform that connects your apps, APIs and databases can carry the records the rest of the way. The document is the input; clean JSON is what lets everything after it be automatic.
Get JSON from your scanned documents
If you are calling raw OCR and hand-writing the mapping to fields, a document extraction API removes that code. The document OCR API returns named fields, tables and confidence as JSON from one call, on scans and digital files alike, and the free tier lets you check the output on your own documents first. For language-specific code, see the Python and JavaScript guides.
Extract your documents with DocuOCR
Upload a document and get clean, structured data in seconds. No template setup required.
Start free