PDF to Text & Markdown: Column-Aware Reading Order

Convert PDFs to clean text and Markdown in the order a human reads them.

Most PDF extractors return text in the order the file happens to draw it, or row by row down the page. On a single-column document that is fine. On a two-column document it is not: the first line of the left column and the first line of the right column share a baseline, so reading straight across welds them together and you get two arguments interleaved sentence by sentence.

The output still looks like text, which is why it usually goes unnoticed until something downstream quietly gives wrong answers.

Measured on a real two-column paper (ResNet, CVPR format, first 12 pages): 265 of 848 rows held text from both columns at once.

Row-major (what column-blind tools return):
  ... classification top-5 LOC error top-5 localization err method network
  testing on GT CLS network on predicted CLS method val test VGG's [41]
  VGG-16 1-crop 33.1 [41] OverFeat [40] (ILSVRC'13) 30.0 29.9 ...

This Actor:
  ... classification top-5 LOC error testing method network on GT CLS network
  on predicted CLS VGG's [41] VGG-16 1-crop 33.1 [41] RPN ResNet-101 1-crop
  13.3 RPN ResNet-101 dense 11.7 ... Table 13. Localization error ...

Two separate tables, kept separate.

What it does

Reading order	Finds the gutter between columns by projecting every text item onto the x axis, then reads each column top to bottom. A full-width title, rule or footer acts as a band separator, so a headline comes out before both columns and a footer after both.
Running heads and page numbers	A line that appears at the top or bottom of at least half the pages is furniture, not content. It is removed, and the row tells you what was removed and from how many pages.
Hyphenated words	inter- on one line plus national on the next becomes international. In justified text this happens dozens of times per document, and every one of them is a token that matches nothing.
Structure	Headings from the document's own font-size distribution (not a fixed table of sizes), bullets and numbered lists, and paragraphs joined only where the line was actually wrapped.
Markdown or plain text	Or both side by side, so you can compare.
Per-page output	Optional, when you need to cite a page number.

What it reports about your batch

Every row carries the numbers behind the claim, so you can check it rather than take it:

• multiColumnPages — pages where a gutter was found
• rowsMergedAcrossColumns — baselines that hold text from two columns at once
• shareOfRowsMerged — the same as a fraction of all rows
• naiveExtractionWouldScramble — true when that count is above zero
• pagesReadAsTables — pages where a gutter was found but the content said "table", so the split was dropped on purpose (see below)
• boilerplateRemoved — the exact running heads that were dropped, and from how many pages
• hyphenJoins, headings, listItems, paragraphs, bodyFontSize
• pagesWithoutTextLayer — pages that are scans

The run also writes a SUMMARY record with the batch totals and the files whose reading order was worst affected.

Input

{
  "pdfUrls": ["https://example.com/report.pdf"],
  "outputFormat": "both",
  "detectMultiColumn": true,
  "removeBoilerplate": true,
  "joinHyphens": true,
  "includePageTexts": false,
  "maxPages": 300
}

Set detectMultiColumn to false to see exactly what a column-blind extractor returns from the same file. That is the honest way to check whether any of this matters for your documents.

Where it deliberately does nothing clever

• It does not run OCR. Pages with no text layer are counted and reported, not read. If a file has no text at all the row comes back as an error saying so. For a full pre-OCR audit of a batch — which pages are scans, what the metadata leaks, whether the file is encrypted — see PDF Inspector.
• One wide table is not two columns. A table of numbers with a gap down the middle projects exactly like a two-column page, but the two want opposite treatment: splitting a table tears every row away from its own values. So after the split is computed it is checked against the content, and a page that reads like cells rather than prose is read row by row instead. The thresholds come from measurement: on real pages, prose columns had 84-92% of lines at six words or more and 88-93% letters, while a page that was one wide numeric table came in at 10% and 49%.
• A gutter blocked by a figure is not found. Where a wide figure, equation or caption fills the gap, the page falls back to row-major order. This is the conservative direction: the page is then no worse than any other extractor's output, and the row still says how many pages were affected.
• No tables are reconstructed. Table text is returned as text. If you need cells as arrays, use a table extractor.
• It does not render or execute anything. No headless browser, no canvas, no JavaScript from inside the documents.

Cost

Free. One HTTP request per file, and the parsing is plain CPU work — no browser, no proxy, no external API. A 12-page paper costs a fraction of a compute unit.

Verification

• 30 unit tests over the geometry: baseline grouping, inferred spaces, gutter detection, the table guard, running-head detection, hyphen joins, paragraph joining, heading levels.
• 27 live checks against real PDFs on the open web, including a two-column paper, a single-column paper (which must not be split), a government form, a one-line PDF and an image-only PDF.

Both suites ship in the source. npm test and npm run test:live.

---

Built by Ai-Q Labs. If it gets something wrong on one of your documents, the fields above are meant to make that visible rather than hide it.