Adding two line items to a client invoice should take thirty seconds. Five rows, four columns, subtotal and tax at the bottom — a clean table. The first time I tried in Adobe Acrobat it took twenty-five minutes. The new text overlapped the totals row. I dragged the totals down, which broke the footer spacing. I nudged the footer, which pushed content into the page margin. By the time the numbers were right, the column alignment was off by a few pixels and the row spacing was visibly inconsistent.
That kind of editing pain is what pushed me to dig into how PDF tables work — and don’t work. The short technical answer is that PDFs don’t store tables; they store positioned text fragments and drawn lines that visually look like one. (I covered that format-level mismatch in detail in why PDF editors can't reflow.) But the practical question is: what do you actually do when you need to edit one?
The three things that break
Three specific operations are where every overlay editor falls over. They’re worth naming, because once you’ve seen the pattern you can predict whether any new tool you try will handle them.
Adding a row. You want a sixth line item on a five-row invoice. In Acrobat there’s no “insert row” — you place a new text fragment, which lands on top of the subtotal. You drag the subtotal down 20 pixels by hand. Tax now overlaps the footer. Move that. The total drifts a pixel or two on the way down. After fifteen minutes the numbers are right and the alignment is wrong.
Widening a cell. Replace a short label with a longer one — “SEO” with “Search Engine Optimization.” The new string runs past the cell boundary into whatever column is next to it. There is no column to widen because the editor doesn’t have a column object; it has text fragments that visually align.
Spanning pages. A 40-row data table on page 2 of a quarterly report. You add 8 new rows. The table should now flow onto page 3 with the header row repeating. In overlay editors the table doesn’t flow anywhere — extra text falls off the bottom edge of the page into invisible space. You manually cut, paste onto page 3, redraw the header row by hand, eyeball the alignment.
All three problems share the same root: there’s no model. Without a model that says “row N belongs to table T which has columns C1..C4 and a total at the bottom,” the editor has nothing to recompute when something changes.
Tool comparison
I tested these on real invoices and reports with non-trivial tables.
| Tool | Add row | Column resize | Multi-page table |
|---|---|---|---|
| Adobe Acrobat | No (manual overlay) | No | No |
| Smallpdf | No | No | No |
| Sejda | No | No | No |
| Google Docs (import PDF) | Partial (loses formatting) | Yes | Yes |
| LibreOffice (import PDF) | Partial (table breaks) | Partial | No |
| ReflowPDF | Yes (right-click menu) | Yes (automatic) | Yes (header repeats) |
The Google Docs workaround is worth knowing about: importing a PDF into Docs converts it to a Google Doc. Tables usually survive. Multi-column layouts, precise spacing, branded headers, and page formatting all break. Fine for extracting data out of a PDF. Useless for producing one that has to look like the original.
LibreOffice Draw can open PDFs, but tables come in as grouped shapes — not real tables. You can move the shapes; you can’t add rows.
Multi-page tables are the actually-hard part
The first two table operations — adding a row, widening a cell — are mechanical once the editor has a structural model. They were the easy part of building ReflowPDF.
The hard part was multi-page tables. When a table spans pages, three constraints fight each other: the row you split on has to be a clean break (no row should be cut in half visually), the header row needs to repeat at the top of every continuation page, and the rest of the document below the table — narrative sections, page numbers, footers — has to reflow against the new page count.
Get any of those wrong and the document looks broken. Header that doesn’t repeat: readers lose context two pages in. Header that repeats but the column widths shifted by 1pt because pagination happened after layout: the table looks subtly off. Footer that doesn’t push to a later page: it lands inside the table.
Browsing issue trackers of every existing PDF library, table header repetition was the single most-requested missing feature. Most libraries just didn’t have it. The ones that did broke when the table grew dynamically. Implementing it correctly meant treating layout and pagination as one pass, not two — same problem that broke flex containers across pages.
What it looks like when it works
Upload an invoice PDF. The AI converts the visual table — text positions plus drawn borders — into a real <table> element with <tr> rows and <td> cells. Column widths are computed from the original PDF coordinates but expressed as flex ratios, so the table adapts to the editor viewport.
From there:
- Right-click any cell → “Insert Row Below.” A new row appears. Subtotal, tax, total all shift down. Page break recomputes if needed.
- Click a cell → type longer text. The column grows. Adjacent columns narrow proportionally.
- Add enough rows to overflow the page. The table splits on a row boundary; the header row appears at the top of the next page; everything after the table on the original page (narrative, footer, page number) shifts to follow.
After editing, export a PDF with the encrypted source embedded. Open the same file later — even months later — and it loads instantly into the editor, no AI conversion, no quality drift.