A PDF does not contain a table

It contains glyphs at coordinates. The rows and columns are an optical effect, so every extraction is an inference — and the honest question is where it was unsure.

A PDF does not contain a table

This is the fact everything else follows from. A PDF contains glyphs, each placed at a coordinate on a page. The rows and columns you can plainly see are an optical effect of that placement. There is no table structure underneath to read out, no cell boundaries, no header markup — nothing to extract in the ordinary sense.

So every tool that gets a table out of a PDF is inferring one, and can be wrong. What separates a good one from a bad one is not accuracy so much as candour: whether it shows you what it inferred and tells you where the inference was weak, or hands you a clean-looking spreadsheet with a column quietly missing.

Finding the columns

The method that works is to look for vertical bands of whitespace that run the height of the table. Where the text never crosses, there is a column boundary.

The obvious alternative — look at where cells start — works beautifully for left-aligned text and fails completely on the right-aligned amounts that make up most of a financial statement. A statement puts descriptions on the left and money on the right, so any method keyed to one alignment mangles the other. Whitespace does not care which way a cell is aligned.

One refinement matters enough to mention: a title line above the table, or a footnote below it, runs the full width of the page and crosses every gap. A single such line is enough to collapse the whole table into one column. Rows holding just one piece of text do not get a vote on where the columns are.

The sign that goes missing

Statements have several ways of writing a credit, and which one you get depends on the system that produced the file:

• (500.00) — the accounting convention
• 500.00- — a trailing minus, still common from mainframe-era systems
• 500.00 CR — an explicit marker
• -500.00 — the obvious one

All four mean negative five hundred. A tool that handles only the last one reads the first as positive five hundred, and that failure is quiet in the worst way: the sign flips on every credit in the file, and the resulting total is wrong but entirely plausible. You would have to add the column up by hand to notice.

The conversions that lose data silently

Exporting to a spreadsheet means deciding what is a number. Two cases are worth getting right, because both destroy information invisibly.

Dates that parse. "03 Jan" will happily read as the number 3 if a parser strips anything that is not a digit. That is not a near miss — it is a date becoming a number, permanently, in a column you will never think to check. The rule that prevents it is simple and slightly costly: letters disqualify a value from being an amount. It also means "1234.56 USD" is not recognised, which is the better trade.

References with leading zeros. "0012345" parses perfectly well and comes back as 12345. Anything that would change when written as a number is kept as text.

And one genuine ambiguity: is 12,345 twelve thousand or twelve point three four five? When both a comma and a dot appear, the last one is the decimal separator — that settles 1,234.56 and 1.234,56 together. When only one appears, exactly three digits after it means a thousands separator. Money is written to two places far more often than three.

How it fails, and how to tell

Everything in one column. No whitespace band ran the full height. Usually two columns are touching; reducing the gap sensitivity helps.

Two columns read as one. The tell is a column that aligns neither left nor right consistently — real columns are one or the other, and a mixture is two columns wearing a trenchcoat.

Extra rows that are not transactions. A long description wrapping onto a second line looks like a row with one cell filled. They are counted and reported, and they almost always belong to the row above.

The header appearing several times. That is a table continued across pages, and the repeats are detected and removed — with a note saying how many, because if the count is surprising, so is something else.

Scans will not work, and cannot

If the PDF is a photograph or a scan, it holds an image of text rather than text. There are no glyph positions, because there are no glyphs. No amount of cleverness in this kind of tool will help; that job is optical character recognition, which is a different problem with a much larger error rate.

The quick test: open the PDF and try to select a line of text. If you cannot, there is nothing there to extract.

Why doing this in the browser matters

A bank statement is about as sensitive as an ordinary document gets. It lists where you were, what you bought, when, and how much you had. Uploading one to a website to convert it means handing all of that to somebody whose retention policy you have not read.

There is no technical need for it. Browsers have had a capable PDF engine available for years, and the whole job — reading the file, inferring the table, building the spreadsheet — runs perfectly well on your own machine. The file never has to leave, so it does not.

Frequently asked questions

Why can extracting a table from a PDF go wrong at all?

Because a PDF contains no table. It contains glyphs placed at coordinates, and the rows and columns are an optical effect of that placement. Every tool that produces a table is inferring one from where the text sits, so the useful question is not whether a tool is accurate but whether it tells you where it was unsure.

How are the columns found?

By looking for vertical bands of whitespace running the height of the table. That works for left-aligned and right-aligned columns alike, which matters because a statement puts descriptions on the left and amounts on the right — any method keyed to where cells start mangles the right-aligned ones.

Are credits handled correctly?

Yes. (500.00), 500.00-, 500.00 CR and -500.00 all mean negative five hundred, and all four are read that way. A tool that handles only the last flips the sign on every credit in the file, and the resulting total is wrong but entirely plausible.

Why is a number in my spreadsheet still text?

Because converting it would lose something. A reference like 0012345 parses fine and comes back as 12345, silently and permanently. Only columns detected as amounts become numbers; dates and references stay text.

Is 12,345 twelve thousand or twelve point three?

Twelve thousand. When both a comma and a dot appear, the last is the decimal separator, which settles 1,234.56 and 1.234,56 together. When only one appears, exactly three digits after it means thousands — money is written to two places far more often than three.

Why did my whole table end up in one column?

No band of whitespace ran the full height, usually because two columns are touching. Lower the gap sensitivity. Title lines that span the page can also close every gap, though single-item rows are excluded from the calculation for that reason.

Will it work on a scanned statement?

No, and no tool of this kind can. A scan is an image of text, so there are no glyph positions to work from. Try selecting a line in your PDF viewer: if you cannot, there is nothing to extract, and the job you need is optical character recognition.

Is my statement uploaded?

No. The PDF is read by pdf.js inside your browser and the spreadsheet is built in the same place; there is no server to upload it to. To be exact about the one request made: the first time you use the page it downloads the pdf.js library from a public code CDN, before you choose a file and carrying nothing about you.