Why Tables Copied From a PDF Come Out Scrambled — the Coordinate Storage Structure
Save a spreadsheet table as a PDF, then pull it back out as text, and you've probably seen columns collapse into one line or numbers land out of order. This isn't because the extraction tool is flimsy — it's a structural phenomenon that arises because the PDF format itself doesn't know what a "table" is. This guide starts from how text is actually stored inside a PDF and works through why tables in particular break.
1. A PDF isn't a "document," it's a "drawing spec on a coordinate plane"
A Word file stores logical structure — paragraphs, tables, cells — as-is. But PDF is a format aimed at reproducing the printed output exactly, so what gets stored is a sequence of instructions: "stamp this glyph at this coordinate (x, y) in this font and size." The concepts of paragraph and table don't exist inside a PDF, and what looks like a table on screen is merely the visual result of number and letter fragments laid out in a grid pattern. To the human eye it's a table, but there's not a single byte of "table" information in the file.
2. In what order does PDF.js pull out text
PDF.js, the standard library that parses PDFs directly in the browser, returns a list of text fragments (items) for a page via getTextContent(). The order of this list is not a "reading order" re-sorted by coordinate — it's exactly the order in which the instructions to draw those characters were recorded inside the PDF file. That order depends on what order the program that made the PDF emitted its drawing instructions: some PDFs draw a table left-to-right, top-to-bottom in order; others draw a whole column first before moving to the next. MODOO HUB's PDF → TXT converter follows this principle directly — it doesn't rearrange fragments by coordinate, it concatenates them in the order getTextContent() returns them, adding a newline only when there's a line-break signal (hasEOL). That means there's no coordinate-sorting logic at all, so the more a PDF's drawing order differs from the visual reading order, the more the extraction result diverges.
3. Why tables break especially badly
Ordinary body paragraphs are mostly drawn top-to-bottom, left-to-right in order, so drawing order and reading order nearly match. That's why body text extracts without much awkwardness. Tables are different. Depending on the PDF generation engine, a table might be drawn row-first (all of row 1 → all of row 2), or column-first (all of column 1 → all of column 2), and it's common to skip empty space at separate coordinates to implement in-cell alignment (center, right). When that order is scrambled, the extracted text ends up looking like "row 1 col 1, row 2 col 1, row 3 col 1, row 1 col 2..." — columns reading like rows — or several rows' values concatenated onto one line. The coordinate information itself remains inside item.transform, but without separate logic to read those coordinates and reconstruct a row/column grid, the original table structure can't be recovered.
| Original table (as seen) | Result extracted in coordinate order |
|---|---|
| Name | Score John | 90 | Name John Score 90 |
4. So how should you deal with it
If you need to extract data accurately from a PDF containing tables, this priority order is realistic. First, if the original was Excel or Word, pulling the data directly from the original file before converting to PDF is the surest. Second, if there's no original, you need a dedicated table-extraction tool with coordinate-based reconstruction logic (an algorithm that groups rows by each fragment's y-coordinate and sorts columns by x-coordinate). Third, if it's a scanned PDF with no text at all, there's no character information before the coordinate problem even applies, so you have to run character recognition first with a PDF OCR tool. If you only need plain body text rather than tables, the PDF → TXT converter gives a perfectly usable result, and to just check page count or rough volume a PDF page counter is faster.
5. The result varies by how the PDF was made
Even with the same table data, extraction quality varies greatly by which program made the PDF. Word's or a word processor's "Save as PDF" usually draws tables row by row in order and breaks relatively little, but a PDF made by printing a web page, or a reporting tool with a complex layout engine (BI tools, accounting software), often reorders drawing arbitrarily for rendering optimization and scrambles much worse. PDFs from the same tool tend to follow consistent rules, so if you repeatedly extract the same table format, figuring out the breakage pattern from a few samples first can cut down manual cleanup time.
Frequently Asked Questions
Q. Is a scrambled table a bug in the tool?
A. No. The PDF format has no logical concept of a table, and text is stored only as coordinate-based drawing instructions, so it's a structural limitation. Most free extraction tools that use PDF.js have the same limit.
Q. Can I fully reconstruct a table using the (x, y) coordinates?
A. You can improve it substantially but not perfectly. Merged cells, cells with line breaks, and tables mixing font sizes often make row/column boundaries ambiguous from coordinates alone, so manual correction may still be needed.
Q. Why can't a scanned paper table be extracted at all?
A. A scanned PDF is a photo of paper stored as an image only — there's no "character" information, just pixels. That's a stage before the coordinate-order problem: you have to run OCR to generate character data before extraction is possible.
Q. Is there a way to make a PDF so tables don't break?
A. You can't fully prevent it, but exporting to PDF directly from a program that explicitly understands table structure — Word, Excel, a word processor — generally draws in row order, producing relatively tidy extraction. Avoid wrapping a printed web page or an image capture into a PDF.