Tested PDF-to-Markdown on Searchable, Scanned, and Table-Heavy PDFs

PDF-to-Markdown conversion is often described as if it were a file-format rewrite:

Read the PDF, emit Markdown, done.

That model breaks as soon as the PDF contains anything more complicated than a single column of selectable text.

I tested four controlled cases in a browser-based converter:

1. a two-page searchable PDF with headings, prose, and a table;
2. a searchable PDF containing a grouped header, a blank cell, and a multiline row label;
3. an image-only scanned PDF;
4. the same kind of scan after OCR added a searchable text layer.

The results were consistent, but not simple:

• searchable text was extracted;
• page boundaries remained identifiable;
• table values survived, but the table grid did not;
• the image-only scan returned no text;
• OCR made the scan extractable, but silently changed identifiers;
• none of the tested outputs became trustworthy Markdown without review.

The important lesson is not that PDF-to-Markdown “works” or “fails.” It is that text recovery, reading order, visual structure, and character accuracy are separate problems.

The test setup

I ran the current MDFold PDF-to-Markdown tool in installed Google Chrome on August 9, 2026.

The controlled fixtures contained no personal or customer data.

Fixture	What it tested	Verification method
Two-page incident memo	Searchable prose, page order, a small table, exact values	Four unique checkpoints and two page markers
Complex regional table	Grouped heading, multiline label, deliberate blank cell	Nineteen labels and values plus visual comparison
Image-only field note	Behavior when no text layer exists	Expected zero extracted words
OCR-processed scans	Recognition errors in clean and difficult pages	Exact source-to-output token comparison

I repeated the complex table and difficult OCR tests at desktop size and at a 390 × 844 phone viewport. The extracted text matched between the two viewports, and the page itself did not overflow horizontally.

This is a controlled product test, not a universal benchmark. Different PDF generators, fonts, tags, languages, rotations, and OCR engines can produce different results.

Case 1: searchable text survived, but the table did not

The first fixture was a two-page incident-review memo. It contained:

• a title and section headings;
• case ID IR-317;
• a three-column table;
• the values Table overflow, 12 pages, and 2026-08-28;
• a second page with scope and ownership notes.

All four checkpoints appeared in the extracted output. Two page markers also appeared in the correct order.

But the table did not become a Markdown pipe table. Its words were present as a flat sequence.

The controlled values and page order survived, but the source table was not reconstructed as Markdown table syntax. Captured August 7 and reproduced August 9, 2026.

This is the first distinction a converter UI can hide:

Complete text is not the same thing as complete structure.

A quick scan of the output might suggest success because every important word is visible. A program expecting | Check | Result | Evidence |, however, would find no table at all.

The correct next step was manual reconstruction based on the original PDF, not guessing columns from spaces in the extracted string.

Why a searchable PDF still has no Markdown structure

A PDF page describes positioned content. Markdown describes document structure.

Those are different models.

Mozilla’s PDF.js API exposes page text through getTextContent(). It exposes a tagged structure tree separately through getStructTree(), and that structure tree may be null. Even when text extraction succeeds, the extractor may not receive a reliable semantic instruction saying:

This line is an H2.
These nine text fragments form a 3 × 3 table.
This empty region is an intentionally blank cell.

Instead, the page may contain text fragments positioned at coordinates. The converter has to infer reading order and relationships from those fragments, unless the PDF contains usable tags or another structural layer.

That inference is where apparently successful conversions become dangerous. The text may be present while its relationships are wrong.

Case 2: every table value survived, but the blank cell became unknowable

The complex table fixture contained:

• a grouped Quarter totals heading;
• Q1 and Q2 subcolumns;
• a multiline North America row label;
• a deliberately blank Q2 cell for Europe;
• a note explaining that blank means “not reported,” not zero.

The source looked like this:

The visual grid carries meaning that is not contained in the individual words. Project-created fixture captured August 5, 2026.

The converter retained all 19 controlled text checkpoints, including:

North America
1,240
1,318
Reviewed
Europe
980
Missing Q2
Asia Pacific
1,105
1,207
Provisional

The output still was not a table:

All labels and values survived, but grouped headers, cell boundaries, and the location of the blank cell did not. Captured August 5 and reproduced August 9, 2026.

From the flat text alone, a cleanup script cannot safely answer:

• whether Quarter totals spans two columns;
• whether North America is one cell or two;
• whether Europe’s missing number belongs to Q1 or Q2;
• whether the blank represents zero, missing data, or a layout gap.

The footnote helps a human recover the intent, but it does not restore the missing cell coordinate.

This is why table verification must be cell-oriented. Counting extracted words or checking that every number appears is insufficient.

Case 3: the image-only scan produced zero text

The third fixture looked like a normal one-page field note in a PDF viewer. It had headings, numbered steps, identifiers, and measurements.

But the PDF contained only page pixels. There was no searchable text layer.

The result in the converter was an empty output: zero words.

The file opened successfully, but there was no text layer to extract. Captured August 5 and reproduced August 9, 2026.

This is not evidence that the document contains no writing. It means the extraction method found no machine-readable text.

OCR must happen before text-based Markdown conversion. OCRmyPDF describes this as adding an OCR text layer to a scanned PDF while retaining the original page image. Once that layer exists, a text extractor has something to read.

The boundary matters: the tested MDFold workflow extracts an existing text layer. It does not perform OCR on the image-only PDF.

Case 4: OCR recovered editable text and introduced silent errors

I processed controlled scans with local OCR, created searchable PDFs from the recognized text, and ran those PDFs through the same converter.

The clear fixture produced 63 editable words. The difficult fixture produced 64.

That sounds successful until the identifiers are compared exactly.

Source	OCR output	Error type
ZX-41	X-41	Character omitted
B0O-518	B00-518	Letter O changed to zero
III.	I.	Roman-numeral characters omitted
OI-1058	0I-1058	Letter O changed to zero

The OCR also correctly retained Café, $1,084.70, 2026-08-05, and a faint REVIEWED 08/05 stamp.

OCR made the scan searchable, but several high-risk tokens changed without an error message. Captured August 5 and reproduced August 9, 2026.

This is a more difficult failure than empty output.

Empty output is visible. A plausible but incorrect asset tag can flow into a repository, search index, or LLM prompt without being noticed.

The safe question is not “Did OCR produce text?” It is:

Which characters would cause harm if one symbol changed?

For many documents, that includes:

• invoice totals;
• dates and times;
• serial numbers;
• case IDs;
• chemical units;
• version strings;
• negative signs and decimal separators;
• names containing accents;
• checkboxes, list numbers, and status labels.

A six-step verification workflow

The following process worked better than treating conversion as one action.

1. Classify the source before converting

Try selecting text in the PDF viewer.

• If normal text can be selected, begin with text extraction.
• If only a rectangular image region can be selected, plan an OCR step.
• If the file mixes searchable and scanned pages, test both page types.
• If tables, columns, figures, or equations carry meaning, plan visual comparison even when the text is searchable.

2. Add checkpoints to controlled tests

For a production pipeline, create a representative fixture with unique values at the beginning, middle, and end.

For example:

{
  "required": ["IR-317", "Table overflow", "12 pages", "2026-08-28"],
  "expectedPages": 2,
  "expectedTables": 1
}

Checking only the opening paragraph will not catch a missing final page or an interrupted reading order.

3. Separate text assertions from structure assertions

These are different tests:

for (const value of requiredValues) {
  assert(markdown.includes(value));
}

assert(markdown.includes("| Check | Result | Evidence |"));

In my searchable fixture, the first assertion passed and the second failed. Reporting a single “conversion passed” result would have hidden the table failure.

4. Rebuild only structure you can prove

Do not infer a table from word order alone when a blank cell or merged header exists.

Open the original PDF beside the Markdown and reconstruct:

• heading levels;
• list boundaries;
• table rows and columns;
• figure captions;
• page-sensitive notes;
• code indentation.

If the structure cannot be proven, keep the content as clearly labelled text or choose a layout-aware extraction tool.

5. Verify exact high-risk tokens

Create a small change ledger:

| Source | Extracted | Decision |
| :--- | :--- | :--- |
| B0O-518 | B00-518 | Correct from source image |
| OI-1058 | 0I-1058 | Correct from source image |

Do this before polishing headings. Semantic cleanup is wasted if the underlying identifiers are wrong.

6. Retain provenance

Keep the PDF until review is complete. Page markers in Markdown can help a reviewer return to the source page.

For high-risk workflows, store:

• the source filename or document ID;
• conversion date and tool version;
• page boundaries;
• OCR engine and language when applicable;
• manual corrections;
• unresolved uncertainties.

Markdown is easier to edit, which is useful. It also makes undocumented corrections easier to hide.

Choose the method by failure mode

Source condition	Reasonable first method	Do not assume
Simple searchable prose	Local text extraction	Heading levels are correct
Searchable PDF with columns	Layout-aware extraction and reading-order review	Text sequence matches visual order
Simple table	Text extraction plus manual cell verification	Spaces reconstruct a grid
Merged or nested table	Table-specific extraction or manual reconstruction	Blank cells and spans survive
Image-only scan	OCR first, then text extraction	Opening the PDF means text exists
Mixed searchable and scanned pages	Per-page detection with OCR fallback	One method handled every page
Equations or diagrams	Visual or specialist extraction	Extracted characters preserve meaning

The best converter is not always the one that produces the prettiest Markdown. It is the one whose failure modes you can detect and whose output you can verify for the document in front of you.

Privacy is a property of the whole pipeline

During the current MDFold tests, I observed no request carrying the PDF to an application conversion endpoint. The extraction happened in the browser.

That is a narrow observation, not a claim that the page is offline. Ordinary analytics requests were still present, and remote page assets can still require a network connection.

The OCR step was separate. I used a local operating-system OCR engine for the controlled scans. A hosted OCR service would have a different data path, retention policy, and risk profile.

Before processing sensitive material, inspect every stage:

PDF storage
  → OCR engine, if needed
  → text extractor
  → cleanup editor
  → repository, search index, or AI system

A local converter cannot make a later cloud OCR or AI upload local.

What this test does not prove

The fixtures were small, English-language documents created for testing. They covered two pages, a grouped table, an intentional blank cell, clean and difficult scans, and a phone-sized browser view.

They did not cover:

• encrypted PDFs;
• handwritten pages;
• right-to-left scripts;
• vertical writing;
• mathematical notation;
• multi-page tables with repeated headers;
• tagged-PDF accessibility quality;
• embedded files or interactive forms;
• every OCR engine or PDF producer.

The test also does not prove that browser-local extraction is more accurate than a hosted or AI-based service. It proves the observed boundary of one current workflow.

If you want the deeper OCR cleanup procedure, I documented the exact-token method in a separate scanned-PDF-to-Markdown guide. For table-specific reconstruction, the PDF table recovery guide includes the controlled blank-cell example.

The acceptance test matters more than the conversion button

After these tests, I no longer describe PDF-to-Markdown as a single conversion.

It is a pipeline:

classify the PDF
  → recover text
  → verify reading order
  → reconstruct proven structure
  → compare exact values
  → retain provenance

For the searchable fixtures, text recovery succeeded while table recovery failed. For the image-only scan, text recovery could not begin until OCR created a layer. For the OCR fixtures, extraction succeeded while character verification still found silent errors.

That leads to a more useful definition of success:

The Markdown is acceptable only when every important fact and relationship can be traced back to the source PDF.

If you have built a PDF ingestion or RAG pipeline, which failure has caused more damage in practice: missing text, wrong reading order, flattened tables, or plausible OCR errors?

Focused FAQ

Can a searchable PDF still produce bad Markdown?

Yes. Searchable text proves that characters can be extracted; it does not prove correct heading levels, reading order, table cells, columns, or figure relationships. Compare the Markdown with the visible PDF structure.

Why does a scanned PDF return an empty result?

An image-only scan has page pixels but no machine-readable text layer. Run OCR first, then verify the recognized text before rebuilding Markdown structure.

Does OCR make the converted Markdown accurate?

Not automatically. In this controlled test, OCR made the scans editable but silently changed four identifiers or list tokens. Exact values still need source comparison.

How should I test a PDF-to-Markdown pipeline?

Use representative fixtures with unique checkpoints, assert text and structure separately, include one image-only and one table-heavy case, compare high-risk tokens exactly, and retain page-level provenance.

Sources

• PDF.js PDFPageProxy API — separate text-content and structure-tree access.
• OCRmyPDF documentation — adding searchable OCR text layers to scanned PDFs.
• Tesseract: Improving OCR output quality — scan quality, segmentation, rotation, and recognition factors.
• W3C PDF6 — table structure in tagged PDF documents.
• GitHub Flavored Markdown table extension — the target pipe-table structure used in the asse