PDF to structured JSON
Convert a Product Catalog PDF to Reviewable JSON
Product catalog PDF-to-JSON extraction turns tables and product blocks into typed records such as SKU, name, brand, attributes, and source evidence. A useful result preserves missing values and validation failures instead of filling gaps, so a reviewer can compare each important field with the supplier document.
Updated August 28, 2026
What useful catalog JSON contains
A catalog is not one flat document. A single product may continue across pages, variants may share a heading, and dimensions may appear in a table whose units are defined elsewhere. The JSON model needs room for stable identity fields, flexible supplier attributes, provenance, and review state.
toSchema uses a versioned supplier-catalog contract. Product identity stays in named fields such as supplier SKU, name, and brand. Supplier-specific specifications stay in typed attributes, while evidence and validation failures remain attached to the record that produced them.
- Keep unknown values absent rather than guessing a SKU, price, unit, or specification.
- Represent repeated product variants as separate records when the source distinguishes them.
- Store page and quote evidence beside the field path it supports.
- Carry the schema version so downstream consumers know which contract they received.
How PDF catalog extraction works
The current product catalog tool accepts one PDF or spreadsheet source and returns schema-validated JSON for review. The sequence separates source parsing from product interpretation so malformed input and unsupported output fail before the result is shown.
- 01
Add the supplier source
Upload a PDF, XLS, XLSX, or CSV file. The source remains the reference for every review decision.
- 02
Extract against the catalog contract
Identify product boundaries and map supported values into stable identity fields and typed attributes.
- 03
Inspect evidence and failures
Review page references, source quotes, confidence, normalization status, and any missing-evidence flags in the JSON result.
Choose JSON when structure matters
JSON is the better intermediate format when products have different attributes, nested evidence, or multiple validation messages. It preserves arrays and typed values without squeezing every supplier variation into a fixed spreadsheet column.
Use the extracted JSON as a review artifact or as input to a downstream transformation. In the catalog workspace, approved records can be mapped with a reusable profile and downloaded as CSV or JSON. The export remains a handoff rather than a direct PIM import.
Illustrative example
Example PDF product block to JSON
The source and output below are illustrative. The output omits price because the source excerpt does not contain one and keeps exact field quotes as evidence.
Supplier PDF · pages 77–78
739-102 | PCB terminal block WAGO · Rated voltage 320 V · 2-pole
Reviewable JSON
{
"schemaVersion": "1.0.0",
"promptVersion": "1.2.0",
"source": {
"sourceHash": "0000000000000000000000000000000000000000000000000000000000000000",
"supplierName": "WAGO",
"title": "PCB Terminal Blocks and Connectors",
"pageCount": 400
},
"products": [
{
"sourceProductKey": "739-102",
"supplierSku": "739-102",
"name": "PCB terminal block",
"brand": "WAGO",
"attributes": {
"ratedVoltage": {
"type": "text",
"value": "320 V"
},
"poles": {
"type": "number",
"value": 2
}
},
"confidence": 0.95,
"fieldEvidence": [
{
"fieldPath": "sourceProductKey",
"pageNumber": 77,
"quote": "739-102",
"sourceHash": "0000000000000000000000000000000000000000000000000000000000000000"
},
{
"fieldPath": "supplierSku",
"pageNumber": 77,
"quote": "739-102",
"sourceHash": "0000000000000000000000000000000000000000000000000000000000000000"
},
{
"fieldPath": "name",
"pageNumber": 77,
"quote": "PCB terminal block",
"sourceHash": "0000000000000000000000000000000000000000000000000000000000000000"
},
{
"fieldPath": "brand",
"pageNumber": 1,
"quote": "WAGO",
"sourceHash": "0000000000000000000000000000000000000000000000000000000000000000"
},
{
"fieldPath": "attributes.ratedVoltage",
"pageNumber": 78,
"quote": "Rated voltage 320 V",
"sourceHash": "0000000000000000000000000000000000000000000000000000000000000000"
},
{
"fieldPath": "attributes.poles",
"pageNumber": 77,
"quote": "2-pole",
"sourceHash": "0000000000000000000000000000000000000000000000000000000000000000"
}
],
"normalizationStatus": "normalized",
"reviewStatus": "pending",
"validationFailures": []
}
]
}This illustrative output is the same fixture validated against the current supplier-catalog contract.
Limitations
- Scanned pages depend on readable OCR; blurred text and low-contrast tables can require manual follow-up.
- A field without source support may be absent or carry a validation failure. It should not be inferred from neighboring products.
- The catalog workspace supports durable jobs, in-product approvals, reusable mapping profiles, and approved-only CSV or JSON exports. It does not connect directly to a PIM.
Frequently asked questions
Can a PDF catalog with tables be converted to JSON?
Yes. A table can be represented as product records when its headers, row boundaries, and units are readable. Cross-page headers, merged cells, and footnotes still need evidence-aware review because their meaning may apply to several rows.
What happens when a catalog field is missing?
The field should remain absent. The catalog contract also supports validation failures and missing-evidence review states so downstream users can distinguish an unknown source value from an empty string or invented default.
Why use JSON before CSV?
JSON preserves nested attributes, evidence arrays, and validation details. After reviewers decide which fields belong in a target system, that richer record can be mapped into a flat CSV without losing the original review context.
Put it into practice