From Pixels to Typed JSON: Structured Data Extraction with One API Call
← All posts
ProductJun 2, 2026· 6 min read

From Pixels to Typed JSON: Structured Data Extraction with One API Call

Most OCR pipelines have an awkward second half. You get clean text out of an image, and then you write brittle regexes, hand-tuned prompts, and parsing glue to turn that text into the handful of values your application actually needs. The OCR was the easy part. The structuring was the tax.

Today that tax is gone. OCRskill now extracts structured JSON directly from images in a single request. You name the fields you want, and the API returns clean, typed values - dates normalized to YYYY-MM-DD, strings trimmed, placeholders rejected - ready to drop straight into a database.

Name Fields, Get JSON

The new endpoint is POST /ocr.json. Add a fields query parameter listing what you need, upload an image, and you’re done:

curl "https://api.ocrskill.com/ocr.json?fields=last_name,first_name,nationality,birthdate" \
  -H "Authorization: Bearer sk-your-key-here" \
  -F "file=@id-card.png"
{
  "last_name": "MUSTERMANN",
  "first_name": "ERIKA",
  "nationality": "DEUTSCH",
  "birthdate": "1964-08-12"
}

Under the hood, OCRskill reads the image, extracts the text, and maps it onto a typed schema built from exactly the fields you requested. You skip the chat-completion boilerplate, the schema wrangling, and the post-processing. One request in, structured data out.

Why This Matters

The point of structured extraction is that the shape of your output is predictable. Required fields are guaranteed present or the request fails loudly with a 400 - no silently empty columns three weeks later. Optional fields (just append ? to the name) are omitted cleanly when they aren’t in the document. Dates come back in ISO format every time. That predictability is what lets you wire OCR straight into a pipeline instead of babysitting it.

Use Cases

Identity documents

Pull last_name, first_name, birthdate, nationality, cnp, id_card_series_number, expiration_date, and more straight from a photo of an ID card. Onboarding and KYC flows that used to need a human in the loop become a single API call.

Invoices and receipts

Extract company_name, invoice_date, or receipt_date from a scan or a phone photo. Feed accounts-payable automation without a template-matching step per vendor.

Vehicle registration documents

OCRskill understands the standardized A-Z fields of vehicle registration certificates: license_plate, vehicle_identification_number, vehicle_brand, vehicle_model, engine_power, first_registration_date, owner_full_address, and the rest. Fleet, insurance, and leasing workflows get a turnkey parser.

Articles and written content

Turn a screenshot of an article into title, sub_title, article_abstract, publish_date, and tags - or ask for concise_summary and let the model write one when the source doesn’t include it. Great for content ingestion and RAG indexing.

Event flyers and posters

Lift event_name, event_venue, event_dates, and a normalized event_date out of a poster image to populate a calendar or listings feed automatically.

Video thumbnail intelligence

For creator-economy analytics, extract thumbnail_hook_text, video_title, video_channel, video_length_str, and date_posted_str from a thumbnail or screenshot. Build datasets of what hooks and titles actually perform, at scale.

Discovery Mode

Not sure which fields a document contains? Drop the fields parameter entirely and OCRskill runs in discovery mode - it considers every supported field optional, extracts whatever is meaningfully present, and returns only the values it actually found:

curl "https://api.ocrskill.com/ocr.json" \
  -H "Authorization: Bearer sk-your-key-here" \
  -F "file=@flyer.jpg"

It’s a fast way to explore a new document type before you lock in an exact schema.

Same Inputs You Already Use

/ocr.json accepts the same image inputs as the plain-markdown /ocr endpoint: multipart form uploads (-F "file=@image.png"), raw binary (--data-binary), and Mistral-style JSON bodies with a document_url data URI. PNG, JPEG, WebP, and GIF are all supported. If you ever want readable text instead of structured fields, the same /ocr endpoint still returns clean Markdown.

Read the Full Reference

The complete list of supported fields, all request formats, the fields syntax for required vs. optional values, and the error-handling details are documented in the Structured OCR JSON API reference.

Grab a free API key and turn your first image into typed JSON in a single call.

Frequently Asked Questions

What is structured data, and why does it matter for OCR?

Structured data is information shaped into named, typed fields rather than loose prose. For OCR it matters because a wall of recognized text still needs parsing, whereas structured data is ready to store and query immediately. OCRskill returns structured data as a clean JSON format keyed by the field names you request.

How is this different from Google structured data or schema structured data markup?

It’s a different use of the phrase. Google structured data (schema.org structured data markup) is JSON-LD you add to a web page so search engines understand its content. The structured data here is the extracted output of a document image. If you searched for “google structured data” hoping to mark up a page, that’s a separate topic; this feature is about turning images into records.

Is there a JSON schema, and what JSON format do I get?

Yes - the output follows a JSON schema generated from the fields you ask for, so the JSON format is predictable on every call. Dates come back as YYYY-MM-DD and strings are trimmed.

Can I do PDF to JSON, PDF to image, or image to PDF?

OCRskill processes images directly. For PDF to JSON, do a PDF to image conversion first (one image per page) and send those to /ocr.json. We don’t ship an image to PDF or PDF to image tool - handle that conversion in your own pipeline, then let OCRskill do the structured extraction.

What about plain image to text, or turning an image to prompt?

For straight image to text, the /ocr endpoint returns Markdown. A popular image to prompt workflow is to OCR an image to Markdown and feed it to an LLM - but if you only need specific values, structured extraction skips that step.

My image text extraction failed - how do I do a cause analysis?

A failed extraction returns a 400 describing the cause: a required field missing from the document, an unknown or duplicate field name, or an unsupported image. The error includes the OCR’d input_text so your cause analysis can see exactly what was read before structuring failed. Marking shaky fields optional with name? usually resolves it.

Does Claude have OCR capabilities? Can I use Claude for OCR?

Claude has some OCR capabilities, and there’s even a Claude Code OCR skill for agentic use. But for accurate, high-volume structured extraction, pairing Claude for OCR orchestration with a dedicated endpoint like OCRskill gives you reliable image text extraction plus typed JSON - the Claude OCR capabilities handle reasoning, OCRskill handles the pixels.

For the full endpoint and field reference, see the Structured OCR JSON API docs.