Why Standard OCR Fails on 500-page PDF Catalogs (And How I Solved It with AI Vision)

AI Export Lab · July 2026

I ran the same catalog page through standard OCR and through Claude's vision model. The OCR output was so garbled I laughed. One line merged a Toyota radiator part number with a Honda condenser description and an unrelated price from two columns away. The AI vision output imported into my database with 6 out of 8 products correct on the first try.

The Catalog Problem Nobody Talks About

I am building jjradiator.com, an auto parts export website. My supplier sent me a 500-page PDF catalog. Radiators, condensers, intercoolers — about 8 products per page, 3-column layouts, OEM part numbers like "16400-0T020" and "MR 508225", vehicle fitment tables, dimension specs.

I needed all of it as structured data. CSV rows I could import. 15,000+ products.

If you work with B2B suppliers in manufacturing, you know these catalogs. They are not clean digital documents. They are internal ERP exports, sometimes printed and re-scanned, formatted for human eyes flipping through a ring binder, not for data pipelines.

I googled "convert PDF catalog to CSV." I tried what came up first.

The results were so bad I kept screenshots.

What Standard OCR Gave Me (Spoiler: Garbage)

I tested three approaches: a free online OCR converter, a desktop PDF-to-CSV tool with good reviews, and Tesseract via a Python script Claude helped me write.

Same page. Same catalog. Three different tools. All produced the same class of failure:

Columns merged across products. The OCR engine scanned left to right, top to bottom, like reading a novel. It had no idea the page had three columns. A radiator part number from column 1 got glued to a condenser description from column 2. The result: nonsense rows where one "product" was actually pieces of three different products.
Tables collapsed into scrambled lists. The fitment table — 4 columns, 6 rows of vehicle models and years — became a flat wall of text. "Toyota Camry 2018 2022 Honda Accord 2019 2023" with no structure. Impossible to parse programmatically.
OEM part numbers got butchered. Dashes became spaces. Slashes became "1"s. A part number like "16400-0T020" came out as "16400 0T020" or worse, "16400 OT020" — one character off, making it useless for database matching.
Scanned pages were worse. Some pages were clearly print-then-scan. Lower contrast, slight skew. The OCR hallucinated characters. "0" became "O". Entire lines vanished where the scan was faint.

After two evenings trying to clean the output with find-and-replace and regex, I did the math:

A single page took me 5 to 8 minutes to manually fix. The catalog had 500 pages. That is 40 to 65 hours of cleanup. For one catalog. From one supplier.

I am a TCM practitioner building this site after work. I do not have 40 hours to clean OCR output.

The problem was not the tools. It was the approach. Standard OCR sees pixels. It looks for dark shapes on a light background and guesses letters. It does not know what a column is. It does not know what a product row is. It cannot read context.

Switching to AI Vision: The Same Page, a Different Result

I stopped treating this as an OCR problem.

Instead of extracting text character by character, I gave the page image to an AI model that could see the whole layout at once — columns, tables, product blocks, the relationship between a part number in the top-left corner and the fitment data in the middle column.

I used two models: Claude for prompt development and the tricky pages with unusual layouts, and DeepSeek's vision API for the bulk processing because it costs almost nothing.

The prompt was not magic. It was specific:

This is a page from an auto parts catalog. It has 3 columns. Each product block contains a part number in the upper-left, a short description, a dimensions table, and vehicle fitment data. Extract every product. Return JSON with fields: part_number, description, dimensions, fitment. Ignore the page header and footer. If a cell is unreadable, mark it null instead of guessing.

That last sentence — "mark it null instead of guessing" — mattered more than I expected. Standard OCR always guesses. AI vision can admit it does not know.

The full database workflow is a separate article (How I Built a 15,000+ Product Database for Under $1 Using Claude and DeepSeek), but the OCR-vs-vision comparison deserves its own space. It is the single technical decision that determined whether this project was possible or not.

Side-by-Side: OCR vs AI Vision on the Same Catalog Page

I took one dense page — 8 products, 3-column layout, some fitment tables spanning multiple rows — and ran it through both pipelines.

Pipeline A: Tesseract OCR → Manual Cleanup

Export the PDF page as a 300 DPI PNG.
Run Tesseract with default settings.
Get back a flat text file. No columns. No structure.
Try to figure out which text belongs to which product.

Result: 3 out of 8 products had usable data after cleanup. The other 5 were unsalvageable without re-typing. Total time for one page: 7 minutes. Extrapolated to 500 pages: roughly 58 hours. I stopped here.

Pipeline B: Claude Vision → JSON → CSV

Same page, same PNG.
Send it to Claude with the prompt above.
Claude returns a JSON array of 8 product objects.
Pipe the JSON into a one-line Python script that writes CSV.

Result: 6 out of 8 products were correct on the first pass. The 2 that failed were a product that spanned two columns (unusual layout) and a product with a blurry part number in a scanned section. Total processing time: about 8 seconds. Spot-checking and fixing the 2 bad rows: about 3 minutes.

If this were a percentage game: OCR gave me ~35% usable data. AI vision gave me ~85% usable data. Both needed human review. But the difference between fixing 65% of rows and fixing 15% of rows is the difference between "this project ships" and "this project dies in a folder of half-cleaned spreadsheets."

Why the Vision Approach Actually Works

It is not magic. There are specific reasons this approach works on structured catalogs where OCR fails:

Layout understanding. I can tell the model "this page has 3 columns, product blocks are separated by horizontal lines, the part number is always top-left." OCR cannot use that information. It just sees pixels.
Context-aware error recovery. When a part number is slightly blurry but the description says "Radiator for Toyota Camry 2018-2022", the model can infer the likely OEM code from context. OCR outputs a question mark and moves on.
Selective attention. Catalog pages often have headers, footers, page numbers, and watermarks mixed with the real data. I can tell the vision model "ignore the header and footer." OCR extracts everything and leaves you to sort it out.
Natural-language field mapping. I say "the column labeled 'OEM No.' maps to 'part_number' in the JSON output." No config file. No regex pattern. No template language. It just works — or it fails in a way I can debug by rewriting the prompt in plain English.

The underlying reason this matters: supplier catalogs are built for human readers. AI vision reads like a human. OCR reads like a machine that was never designed for this type of document. For dense, structured B2B catalogs, that is the only difference that matters.

What It Cost (Less Than You Think)

Processing all 500 pages through DeepSeek's vision API cost under 5 RMB. At current rates, that is less than one US dollar.

The split: DeepSeek handled roughly 90% of the pages — the clean, consistent, well-structured ones. Claude handled the remaining 10% — odd layouts, ambiguous data, pages where I needed better reasoning to get the extraction right.

DeepSeek's vision pricing is a fraction of what most developers in the US or Europe assume AI vision costs. The total token burn across 500 pages was comparable to one long conversation thread. Not a data-center-scale operation. Not a enterprise AI budget.

To ground this in real alternatives: hiring a VA to manually type 15,000 product rows from a PDF costs $200–$500, takes weeks, and you still have to verify every row. The AI approach cost less than a dollar in API fees and about two weeks of evening sessions — most of that spent reviewing output and fixing edge cases, not on the extraction itself.

The API cost is so low it is not the bottleneck. Your time reviewing the output is the bottleneck. That does not go away — but it shrinks from "impossible to finish" to "manageable in evenings."

What Still Breaks

I do not want this to read like a success story where everything worked. Here is what still fails:

Handwritten notes on scanned pages. If someone wrote on the catalog before scanning it, the model tries to incorporate the handwriting into the product data. A scribbled "discontinued" in the margin becomes a product attribute.
Tables inside tables. Some pages had a master product-family table with nested variant rows inside it. The model sometimes flattened the hierarchy, merging variants into the parent row.
Inconsistent field names across suppliers. One supplier labels a field "OEM No.", another "Ref. No.", another "Part Code." The model extracts the value correctly, but mapping field names across different suppliers is still manual.
Non-Latin characters mixed with part numbers. Some catalogs had Chinese annotations next to English part numbers. The model occasionally merged them into one garbled string.

The honest number: AI vision gets me 85–90% of the way there with almost no effort. The last 10–15% still takes a human who knows the product domain and can spot when something looks wrong. If you expect 100% automation, you will be disappointed. If you are a solo operator who just needs the heavy lifting done, this approach changes the math.

Is This Worth Trying for Your Catalogs?

Probably yes, if:

Your PDF has structure. Even loose structure is fine. If every page is a random collage of images with no consistent layout, neither OCR nor AI vision will save you. But if products repeat a pattern — same columns, same fields, same visual hierarchy — the vision model can latch onto it.
You can review the output. Do not expect to pipe the JSON directly into your production database with zero checking. Budget an evening or two for spot-checking. The model will get some rows wrong. The question is whether wrong-15%-of-the-time is better than manually-typing-100%-of-the-time. For me, it was not close.
You can set up API access. The free chat interfaces cannot handle 500 pages. You need API keys. The setup takes an hour. The cost is so low it is barely worth tracking.

For me, the math was straightforward: retype 15,000 products by hand over several months, or write a good prompt in two evenings and let AI do the extraction while I check samples. There was no third option that fit my constraints — no budget, no team, working after hours.

If those are your constraints too, skip the OCR tools. Go straight to vision.

Still Stuck with a Messy Supplier Catalog?

If you have a chaotic, multi-page PDF catalog and do not want to spend weeks cleaning data, send a 2-page sample through my Contact page. I am happy to take a look and tell you which AI workflow fits your specific document structure.

No pitch. No obligation. I have spent enough evenings staring at garbled OCR output to know what works and what does not — and I can usually tell from two sample pages.