Extracted PDF text has both columns mashed together

You pulled the text out of a 22-page journal article and the first line of your .txt file reads:

Introduction to the survey design the sample was drawn from four districts

Those are two different sentences from two different columns, welded together. Every word is correct. The order is wrong, and it is wrong the same way on all 22 pages.

Nothing is broken. This is a direct consequence of how PDF Text Extract rebuilds lines, and once you know the rule you can predict exactly which documents it will happen to.

The eight-point rule

A PDF does not store paragraphs. It stores runs of characters, each with a position on the page, and nothing that says "this run belongs to that one". A text extractor has to infer the lines back.

The inference here works in three steps for every page:

1. Collect every non-empty text run with its x and y coordinates.
2. Sort them all by vertical position, then group runs whose baselines sit within 8 points of each other into a single line.
3. Sort each of those groups left to right, join with spaces, and collapse repeated whitespace to one space.

On an ordinary single-column report that reconstructs the page almost perfectly. On a two-column layout it fails in a completely predictable way, because the first line of the left column and the first line of the right column are printed at the same height. Their baselines are well within 8 points of each other. So they are one line as far as the rule is concerned, and the left run gets written before the right run.

Eight points is not an arbitrary choice, incidentally. It is loose enough to survive subscripts, a footnote marker set two points higher than its line, and a heading where one word is in a slightly larger face. Tighten it and single lines start splintering into three. There is no threshold that gets both cases right, because the information needed to tell them apart is not in the coordinates.

Everything else this explains

Column interleaving is the visible symptom. The same rule produces several others:

• Running headers and footers land inside the text. The journal name at the top of every page and the page number at the bottom are runs like any other, so they appear at the start and end of each page's block. On a 200-page book that is 400 stray lines.
• Pull quotes and sidebars drop into the middle of a paragraph. A boxed note beside the third paragraph shares baselines with it, so it is spliced in there.
• Table columns lose their boundaries. A table row genuinely is one line, so the row survives — but because runs of whitespace collapse to a single space, you cannot tell which spaces were column gaps and which were word gaps. Basmati Rice 5 kg 25 1200 gives you no way to know where the description ended.
• Marginal notes and vertical labels appear at whatever height their baseline sits at, regardless of the fact that a human reads them separately or turns the page sideways.

Before you fix anything, ask whether you need to

A surprising share of the time the interleaving does not matter at all.

If you are searching a 400-page tender document for the word "arbitration", the order is irrelevant — you need the hit and the page number, and the extraction gives you both. Same for a word count, for feeding text into a translation box paragraph by paragraph, or for checking whether a clause appears anywhere in an agreement.

Spend the effort on layout only when the output is going to be read as prose or reused as a document.

When you do need the order right

Use the reading-order reconstruction in Advanced OCR. Advanced OCR solves this properly rather than working around it. It analyses the page into blocks, assigns each block to a column, then emits each column top-to-bottom and the columns left-to-right — with running headers pulled to the front and footers pushed to the back, regardless of where they physically sit. A page number printed at the top of the second column is still treated as a footer. That is the behaviour you want on a journal article, a two-column government notification, or a newspaper clipping.

The trade is speed. Reading-order analysis is a heavier process than sorting coordinates, and on a long document you will feel it. Run it on the pages that need it rather than all 200.

Convert to Word instead of text. When what you actually want is a document rather than raw words, PDF to Word keeps the structure — columns as columns, tables as tables — and hands you something you can edit rather than something you have to re-flow by hand.

Isolate the pages first. If only a handful of pages inside a long PDF are two-column, pull them out with Split PDF and treat that short file differently from the rest. Extracting text from 190 single-column pages works fine; it is the 12 awkward ones that need the slower route.

The one case where you can un-weave it yourself

A strictly two-column layout with equal column widths and no floating figures interleaves regularly enough to reverse by hand. Every output line is one left-column line followed by one right-column line, and the join is at a point where a sentence stops making sense mid-phrase.

For half a page that is faster than any tool. For anything longer, or for a layout with figures that break the columns partway down, the pattern stops holding and you will spend more time repairing errors than you saved.

What the extraction does get exactly right

It is worth being clear about the boundary, because the tool is genuinely precise where it counts.

Every character in the output is the character in the file. Nothing is recognised, guessed or corrected — the text layer is read directly, so an account number comes out as the account number and a Devanagari heading comes out in Devanagari. That is a meaningfully different guarantee from OCR, where every character carries a probability.

Pages are marked in the output as --- Page 3 ---, so you always know which page a passage came from even after the columns have been scrambled. The result panel reports the page count and total character count, and you can copy the text straight to the clipboard or download it as a .txt named after the original PDF.

The whole thing runs in your browser, off the main thread, with a ceiling of 1 GB per file. Nothing is uploaded, which is why an internal audit report or a signed contract is a reasonable thing to run through it.

And if nothing comes out at all

A different failure with a different cause: No text found. This PDF may be scanned (image-based).

That means the file has no text layer — it is photographs of pages, and there is nothing to sort into lines. No setting fixes it, because the words are not there as characters. That is the case OCR exists for, and the scanner tools are where to go next.

Quick way to tell the two apart before you start: open the PDF in any viewer and try to drag-select a sentence. If the selection highlights, the text layer exists and extraction will work — the only question is what order it comes out in.