Guide
How to extract product data from PDFs
Supplier PDFs hold the specifications your catalog needs, but not in a form you can import. Here are four ways to turn them into structured product data, and how to choose between them.
Product data extraction means taking the values printed in a document — model numbers, dimensions, materials, capacities, ratings, warnings — and turning them into fields a system can use. For a handful of products, copying by hand is fine. For a supplier catalog with hundreds of SKUs and a different PDF layout from every manufacturer, the method you choose decides how long onboarding takes and how many errors reach your store.
Below we compare the four common approaches, then cover the checks that matter regardless of method.
Start with the output: define your product schema
Before extracting anything, decide which fields you need and in what form. A schema for a small appliance might include model, brand, EAN, width/height/depth in millimetres, weight in kilograms, power in watts, voltage, material, colour, and warnings. Defining units and allowed values up front is what makes the extracted data comparable across suppliers.
If you sell on several channels, map each field to the attribute names those channels use (for example, Shopify product options or WooCommerce attributes), so the extraction output can be reused without another round of reformatting.
Method 1: Manual copy and paste
Someone opens the PDF and types or pastes values into a spreadsheet or product form. It needs no tooling and handles any layout, which is why most teams start here.
The costs grow with volume: it is slow, attention drifts, and transcription errors — a swapped digit in a model number, a value from the wrong column — are hard to spot later. Manual entry works for small catalogs or as the review step on top of an automated method.
Method 2: PDF table extraction tools
Table extraction tools (including open-source options and the export features of PDF editors) detect tables in digital PDFs and export them to CSV or Excel. They are fast when the data really is in a clean table.
They struggle with values written in running text, merged cells, multi-page tables, and scanned documents, and they return raw tables rather than named fields — you still have to map columns to your schema and clean up headers, units, and footnotes.
Method 3: Template or zonal parsing
Template-based parsers let you define, for a given layout, where each field sits on the page. Once configured, every document in that exact layout is extracted consistently, which suits high volumes of identical documents such as invoices from one sender.
Supplier data sheets are rarely that uniform. Each manufacturer — and often each product line — needs its own template, and templates break when the supplier changes the design. For catalogs sourced from many suppliers, maintenance quickly outweighs the gains.
Method 4: AI extraction
AI extraction uses language and vision models to read the document the way a person would: it finds the model number whether it is in a header, a table, or a sentence, and returns the fields of your schema with values and units. Because it does not depend on fixed positions, one setup can handle many supplier layouts, including scanned pages.
The trade-off is that AI output must be reviewed. Good tools show a confidence indication and source evidence for the extracted values so reviewers can focus on uncertain ones, and they leave a field empty or flagged rather than guessing when the document does not state it. Doc2Shelf’s PDF product data extraction scores each extraction for confidence and completeness and records extracted facts with their page and a short quote; the reviewed record can feed listings and compliance drafts.
How to choose a method
A practical rule of thumb:
- Under roughly 20 products, or one-off additions: manual entry with a clear schema.
- Clean digital tables, one or two suppliers: a table extraction tool plus cleanup.
- Large volumes of one identical layout: template parsing.
- Many suppliers, varied layouts, or scanned PDFs: AI extraction with human review.
Checks that keep extracted data accurate
Whichever method you use, the same issues cause most errors. Build these checks into your review step:
- Model mapping: when a sheet covers several models, confirm each value belongs to the right model column.
- Units: normalize units (mm vs cm, W vs kW) and keep the unit with every numeric value.
- Footnotes and conditions: values such as capacity or runtime often depend on stated test conditions.
- Identifiers: verify EAN/GTIN check digits and model numbers character by character.
- Missing or conflicting values: ask the supplier rather than inferring a value that is not in the document.
- Traceability: keep the source PDF linked to the record so anyone can re-check a value later.
Extraction methods compared side by side
The four methods above differ less in what they can read than in what drives their accuracy and how much setup they need. OCR belongs in the comparison too, but as a layer rather than a method: it turns a scanned page into text, and one of the other methods still has to turn that text into fields.
Accuracy is never a property of the method alone. It depends on the documents you feed in, how clearly your schema defines each field, and how disciplined the review step is — which is why it is worth measuring on a sample of your own supplier PDFs rather than relying on published figures.
| Method | Accuracy depends on | Setup effort | Output | Best for |
|---|---|---|---|---|
| Manual entry | Reviewer attention and a clear schema | None | Named fields, as typed | Small catalogs; one-off additions; the review step |
| Copy-paste or PDF-to-Excel export | A real text layer and clean, unmerged tables | Low | Raw text or tables to map by hand | Clean digital tables from one or two suppliers |
| Template or zonal parsing | Every document keeping an identical layout | High per layout, again when layouts change | Named fields | High volumes of one fixed layout |
| OCR | Scan resolution, contrast, skew, fonts, language | Low to medium | Text only | Making scanned pages readable for another method |
| LLM-based extraction | Schema clarity, document quality, review discipline | Low per layout; needs a review workflow | Named fields with values and units | Many suppliers, varied layouts, mixed prose and tables |
Handling spec tables and multi-variant tables
Most extraction errors on datasheets happen in tables, and most of those happen when one table describes several models. A table that looks obvious to a reader hides structure a parser or a tired person can get wrong: units that appear only in the header, cells merged across models, footnote markers attached to numbers, and tables that continue on the next page.
Work through each spec table in a fixed order before any value is copied into a record:
- Identify the orientation: are models or variants in columns or in rows? Note how many there are, so you can check the record count at the end.
- Read every header row, including units in brackets, and carry the unit down to each cell in that column or row.
- Expand merged cells: a value spanning several model columns applies to each of those models, not only the first.
- Rejoin tables split across pages, checking that the repeated header is not read as a data row and that no row is lost at the page break.
- Separate footnote markers from numbers — “1.1¹” is 1.1 with footnote 1, not 1.11 — and store the footnote text as a condition on that value.
- Distinguish blank, “—”, “n/a”, and “optional”: blank means unknown, a dash often means not applicable, and neither should become zero.
- Look for values outside the table, such as “all models: 230 V” beneath it, and apply them to every model they cover.
- Split the table into one record per model or variant, then confirm the record count matches step 1.
Scanned PDFs and OCR quality
First check whether a PDF has a text layer: if you can select or search the text, it is digital; if not, it is an image and needs OCR before any table tool can read it. When a supplier sends a scan, ask for the digital original — it removes a whole category of errors. If you must scan yourself, a resolution of around 300 dpi is a common recommendation for text, and straight, high-contrast pages matter as much as resolution.
OCR errors are dangerous because they produce plausible output. The characters that get confused are predictable, so the checks can be too:
| OCR error | Example | How to catch it |
|---|---|---|
| Letters and digits confused (O/0, l/1, S/5, B/8) | “AX-1OO” instead of AX-100 | Pattern checks on model numbers; GTIN check digit |
| Decimal separator lost | “1,5 l” read as “15 l” | Plausibility range per attribute |
| Footnote merged into a number | “1.1¹ kg” read as “1.11 kg” | Compare with sibling models; look for footnote text |
| Wrong reading order | Two columns joined into one line | Check value counts per model |
| Unit symbols misread | “°C” as “oC”, “µm” as “um” | Allowed-unit list per attribute |
| Minus sign or dash dropped | “−20 °C” read as “20 °C” | Check that range minimum ≤ maximum |
Worked example: a datasheet becomes a structured record
Here is how the steps above apply to one illustrative kettle datasheet that covers two models in one table. It is a teaching example, not a real product or a measured extraction result. Each source line is mapped to a field, normalized, and checked.
The result is two variant records sharing capacity, power, and voltage, each with its own color, weight, and identifier — plus two open questions for the supplier. Nothing was filled in by assumption: the second model’s EAN and the country of origin stay empty until the supplier provides them. Normalizing values and units across many suppliers, rather than one sheet, is covered in the guide to product attributes.
| Source line as printed | Field | Extracted value | Check applied |
|---|---|---|---|
| Model: AX-100 | AX-100B | model_number | AX-100; AX-100B | Two columns, so two variant records |
| Capacity 1,5 l (merged across both models) | capacity | 1.5 L for each model | Decimal comma; merged cell copied to both |
| Power 1850–2200 W | rated_power | min 1850 W, max 2200 W | Kept as a range, not one number |
| 220–240 V~ 50/60 Hz | rated_voltage; frequency | 220–240 V AC; 50/60 Hz | One line, two fields |
| Colour: brushed steel | black | color | brushed steel; black | One value per variant |
| Net weight (kg) 1.1¹ | 1.0¹ | net_weight | 1.1 kg; 1.0 kg | Unit from header; footnote ¹ “without base” kept |
| EAN 6291041500213 | — | gtin | 6291041500213; empty | Check digit valid; ask for the missing EAN |
| (not stated) | country_of_origin | empty | Request from supplier; never inferred |
Common failure modes and a verification workflow
The same handful of document features cause most extraction errors, regardless of method. Knowing them lets you design the review around the real risks rather than re-reading every value with equal care.
- Confirm the document: right product, current revision, all pages present.
- Check every identifier (model number, GTIN with its check digit) and every safety-relevant value — warnings, electrical ratings, hazard information — against the source.
- Run automatic checks on the rest: units present, values within plausible ranges, required fields filled.
- Spot-check a sample of the remaining fields per supplier, and widen the sample when you find errors.
- Turn unresolved gaps into questions for the supplier instead of estimates.
- Store the source PDF, the reviewer, and the review date with the record.
| Failure mode | What goes wrong | Prevention |
|---|---|---|
| Units only in headers | Bare numbers lose their unit | Carry header units down; reject unitless measurements |
| Footnotes and test conditions | “Typical”, “at 25 °C”, or “without base” is dropped | Store conditions with the value |
| Merged cells | Value assigned to the first model only | Expand merged cells before splitting variants |
| Multilingual datasheets | Decimal commas misread; same value captured twice in two languages | Locale-aware number parsing; header synonym list; deduplicate |
| Several products in one PDF | Values attached to the wrong product | One record per product; check each model number |
| Outdated revisions | An old sheet contradicts the current one | Record document date or revision; prefer the latest |
| Values only in drawings or images | Dimensions on a technical drawing are missed | Check drawings; flag missing dimensions |
Frequently asked questions
- Can I extract data from a scanned PDF?
- Yes, but the text must be recognized first with OCR (optical character recognition). Table tools that only read digital text will return nothing from a scanned page; OCR-capable and AI-based tools can read it, with more care needed on low-quality scans.
- How do I extract product attributes from a PDF datasheet?
- Define the attributes you need (for example material, colour, capacity), then pull values from the datasheet’s tables and text, either manually or with an AI tool that maps table cells and sentences to fields. Treat attributes stated only in marketing copy with caution and confirm technical values against the specification tables.
- What format should extracted product data be in?
- Use whatever your downstream system imports — usually CSV for spreadsheets and store importers, or JSON for APIs and PIM systems. Keep one row or object per product variant, with consistent field names and units.
- Is AI extraction accurate enough to publish without review?
- It should not be published unreviewed. AI extraction removes most of the typing, but a person should confirm uncertain fields, identifiers, and anything safety-related against the source document before the data is used.
- What is the best way to extract tables from a PDF datasheet?
- For clean digital tables, a table extraction tool or an AI extraction tool both work; scanned tables need OCR first. Whatever the tool, expand merged cells, carry header units down to each value, separate footnote markers from numbers, and split multi-model tables into one record per model.
- How accurate is AI extraction of product data from PDFs?
- It depends on document quality, layout complexity, and how clearly you define the fields, so there is no single accuracy figure that applies to your documents. Measure it yourself: extract a sample of your supplier PDFs and compare each field with the source, counting wrong and missing values separately.
- Can I convert a PDF catalog into a CSV for my store?
- Yes. Extract one record per product or variant into a fixed set of columns, normalize units and values, then rename columns to match your store’s import template. A catalog often has less detail per product than individual datasheets, so expect gaps to fill from other sources.
- How do I extract data from datasheets in other languages?
- Keep values as printed during extraction, parse numbers using the document’s locale (decimal commas, thousands separators), and map foreign-language headers to your field names with a synonym list. Translate descriptive text separately, and have it reviewed.