How PDF to Text Handles Line Breaks and Tables

Headings collapse to plain lines

PDF to Word and PDF to HTML can express a detected heading as real markup with visible emphasis — bold text, a larger size, an actual heading tag. A .txt file has none of that available. A heading line extracted by PDF to Text is exactly the same kind of line as a body paragraph: no bold, no larger size, nothing to visually set it apart, just its plain characters in reading order. If you need a heading to still look like a heading after conversion, PDF to Word or PDF to HTML are the correct output formats, not PDF to Text.

Detected tables become pipe-joined lines, not a grid

PDF to Text runs the same table-detection logic used elsewhere on the site — looking for runs of consecutive lines with recurring column positions — but a .txt file has no columns and no grid to place the result into. Each detected table row is serialized as a single line of text with its cells joined by " | " (space, pipe, space). A three-column row like Item / Qty / Price becomes one line reading "Widget | 4 | $12.00" rather than aligned columns with visible borders.

This is a deliberate structural simplification, not a rendering bug. Contrast this with pdf-to-word-table-reconstruction-explained, which covers the same underlying detection logic used to rebuild an actual editable table in a Word document — there, the goal is to preserve the grid; here, in a plain-text file, there simply is no grid to preserve, only a readable line-per-row approximation of one.

The form-feed character marks page breaks

Between each page’s extracted text, PDF to Text inserts a form-feed character (\f) followed by a blank line. Form feed is a long-established plain-text convention that many text editors, printers, and command-line tools already recognize as "start a new page" — so a script processing the downloaded file can split on \f to recover the original per-page boundaries, even though a .txt file otherwise carries no page markup at all. If you open the file in a plain text viewer, the form-feed character is usually invisible or shows as a small page-break glyph rather than printable text.

Multi-column layouts can read out of order

Extraction order is driven by each line’s position on the page — primarily its vertical position, then its horizontal position — not by which visual column a human reader would naturally follow next. On an ordinary single-column page, that always matches normal reading order, because there is only one column to walk down.

On a genuinely multi-column layout — a two-column newsletter, an academic paper with side-by-side columns — a line near the top of the second column can sit at roughly the same height on the page as a line in the middle of the first column. Because lines are grouped mainly by vertical position, text from both columns can end up interleaved rather than reading all the way down column one before moving to column two. This is not unique to plain text — the same position-driven reading order underlies every PDF-to-X tool on the site — but it is more noticeable in a .txt file, since there is no paragraph or heading structure to visually disguise the jump.