Why supplier PDFs are the worst source of product data

A supplier sends a 200-page PDF catalogue with every product, every specification and every drawing. It looks like the answer. It is, in practice, the hardest source of product data you will work with — harder than the website, harder than a badly formatted spreadsheet, and harder than the phone.

The reason is a technical fact about the format that is worth understanding before you commit a fortnight to extracting from one.

What a PDF actually contains

A PDF does not contain a table. It contains instructions for placing marks on a page: put this glyph at these coordinates, draw a line from here to here.

What you see as a specification table is, to a machine, a set of characters at positions with some lines nearby. The rows and columns you perceive are an artefact of the spacing. There is usually no structure recording that "24" belongs to "Supply voltage" — that relationship exists in your eye, not in the file.

Extraction tools reconstruct the table by inferring structure from position. That inference works well on simple layouts and degrades in ways that are hard to detect.

Where extraction breaks

Five failure modes, roughly in order of how often they cause trouble:

1. 01Merged cells. A cell spanning two columns breaks column inference for the whole table, usually shifting values one column left from that row down.
2. 02Multi-line cells. A long description wrapping to three lines is read as three rows, and the values beside it are silently misaligned.
3. 03Footnotes and superscripts. A superscript reference marker attaches to the value: 24¹ becomes "241". This one is dangerous because the result looks like a plausible number.
4. 04Units in headers. "Voltage (V)" as a header with bare numbers beneath is fine. Mixed — some rows with units, some without — produces a column that is half numeric and half text.
5. 05Rotated or image-based tables. A table saved as an image contains no text at all. OCR helps and introduces its own errors, particularly with 0/O and 1/l.

The common thread is that failures are silent. A broken extraction does not throw an error; it produces a table that looks fine and is wrong in the middle. You find out when a customer receives the wrong part.

The honest comparison with a website

The same manufacturer usually publishes the same products on their website, where the specification lives in actual HTML markup — a real table, with real cells, with a real relationship between label and value.

The website wins on every row that matters. It feels more manual because you can see yourself clicking through it, but for a machine it is substantially more tractable.

When a PDF is genuinely the right source

Three cases, to be fair to the format:

• The product is not on the website — discontinued ranges and regional variants often only exist in print.
• The PDF contains information the website omits, which is common for dimensioned drawings and compliance detail.
• The datasheet itself, which should be captured and hosted as a file rather than extracted from.

That last point is worth separating clearly. Capturing a PDF as a file is easy and valuable. Extracting structured data out of a PDF is hard and unreliable. Do the first freely; approach the second with caution.

What to ask the supplier instead

Before committing to extraction, ask. The request costs an email and succeeds more often than people expect, because the data usually exists in a system the marketing department exported the PDF from.

Ask for: "a CSV or Excel export of your product list, with one row per part number, including the specification attributes as separate columns." Roughly a third of suppliers can produce this within a week.

If the answer is no, use the website rather than the PDF, and reserve extraction for the products that genuinely exist nowhere else. Whatever you extract from a PDF, review it by hand — because that is the one source where you cannot trust the output to fail visibly.