Extract data from PDF to Excel: a practical guide for analysts

Somewhere in almost every organisation there is a monthly ritual: an analyst opens a PDF full of figures, and begins the tedious, error-prone work of typing it into a spreadsheet. Bank statements, supplier invoices, annual reports, government statistics — the data exists, but only as a picture of a table, and someone has to retype it.

PDF-to-Excel extraction exists to end that ritual. Done well, it turns a twenty-minute typing job into a two-second conversion plus a short review. Done badly, it produces a mess that takes longer to fix than to retype. This guide explains why PDF tables are difficult, how the detection methods differ, and how to run a workflow that produces clean, trustworthy spreadsheets.

If you want to try it immediately, the PDF to Excel tool runs entirely in your browser. Read on to understand what it is doing and how to get the best results.

Why extracting tables from PDF is genuinely hard

To a human, a table is obvious: rows, columns, headers, cells. To a PDF, a table does not exist. A PDF knows only that a particular glyph was drawn at a particular coordinate in a particular font. There is no 'table object', no 'cell', not even a 'row'.

So table extraction is really a computer-vision-and-layout problem: given a cloud of positioned text runs, infer the rectangular grid a human would have perceived. Researchers have worked on this for decades, and while modern methods are very good on conventional documents, no approach handles every layout perfectly.

Two properties of PDFs make the problem tractable. First, most business tables align their columns consistently, so the x-coordinates of cell contents cluster into vertical bands. Second, many tables have visible borders, which are drawn as graphics and can be detected directly. A good extractor exploits both signals.

The two families of PDF tables

Practically speaking, tables you meet in the wild fall into two families, and they demand different techniques.

Ruled tables

These have visible horizontal and vertical lines. The extractor identifies the line graphics, treats the intersections as cell boundaries, and assigns each piece of text to the cell that contains it. This is the easy case, and it is extremely reliable — a ruled table almost always converts cleanly.

Whitespace tables

These have no lines; alignment alone separates the columns. This is the harder and, unfortunately, more common case. The extractor must infer column boundaries from the statistics of where text starts and stops. It sorts runs into row candidates by vertical position, computes a histogram of their horizontal start positions, finds peaks in that histogram, and snaps each run to the nearest column. When column alignment is consistent, this works remarkably well; when it drifts — as it often does in scanned or hand-adjusted documents — it produces columns that merge or split.

Ninety-five percent of invoices, bank statements and exported reports are the whitespace variety, which is why table extraction is the hardest common PDF task.

How the nctools extraction pipeline works

Under the hood, PDF to Excel runs a five-stage pipeline entirely in the browser, using Mozilla's pdfjs-dist to read the file and SheetJS to write the spreadsheet.

1. Read the text runs and their bounding boxes from the PDF, page by page, using the same parser that powers Firefox's PDF viewer.
2. Group runs into row candidates by sorting on vertical position and clustering runs whose baselines are close.
3. Compute a horizontal histogram of run start positions across each page to find the column bands.
4. Locate peaks in the histogram — those are column boundaries — and snap every run to its nearest column, producing a rectangular matrix.
5. Write the matrix into a valid .xlsx workbook with SheetJS, preserving numbers as numbers so Excel can compute with them.

Because the file never leaves your device, the pipeline runs on your own CPU. On a modern laptop a dense twenty-page financial statement extracts in a few seconds. Nothing is uploaded, which matters a great deal when the tables contain salaries, account numbers, or client billing.

Step-by-step: PDF to Excel without retyping

Here is the working procedure we recommend, using the PDF to Excel tool.

1. Trim the source if you can — export or crop just the pages containing the tables. Cleaner input, cleaner output.
2. Drop the file onto the tool. It is read locally into browser memory.
3. Let the tool detect tables across the pages; each detected table becomes a worksheet region.
4. Download the .xlsx file and open it in Excel, Google Sheets, or LibreOffice.
5. Review the header row and the first and last rows of each table — those are where detection errors concentrate.
6. Spot-check a handful of figures against the PDF, especially any that will drive decisions or reporting.
7. Apply number formatting, then build your pivot tables or formulas on top of the clean data.

The review steps matter. An extraction that is ninety-eight percent correct is enormously valuable, but in a financial context the two percent is exactly what you cannot afford to miss. Reading the extracted numbers against the source in the highest-value rows is a five-minute investment that protects the whole analysis.

When tables do not extract cleanly

If your output is one long column, or columns that bleed into each other, the cause is almost always one of a few specific issues. Diagnosing them is quick.

• No borders and drifting columns — the extractor cannot find stable column bands. Fix: export the table's page alone, or re-scan at higher resolution so spacing is consistent.
• It is actually a scan — if text is not selectable in the PDF, there is no text layer to extract. Run PDF to OCR first; the guide on extracting text from images and scans covers that workflow.
• Merged cells and multi-row headers — span metadata is lost. Fix: rebuild those header rows manually; the data below is still correct.
• Multiple tables on one page — the extractor may merge them. Fix: separate them in Excel after extraction, or split the page into single-table pages first.
• Footnotes woven into the table — small-print footnotes can be captured as data rows. Fix: delete them after extraction; they are easy to spot at the bottom of the sheet.

A useful rule of thumb: if a table would be easy to describe to a colleague in words ('three columns, one row per invoice, header on top'), it will extract cleanly. If describing it requires a drawing, expect to do some assembly.

Which documents benefit most

Some document types are close to ideal for automated extraction, and knowing which are which sets your expectations correctly.

• Bank and credit-card statements — highly structured, consistent columns, excellent extraction targets.
• Supplier invoices — usually clean once you isolate one invoice template; batch extraction of the same supplier works well.
• Financial statements and annual reports — the main tables extract cleanly; the narrative pages need a different approach.
• Price lists and product catalogues — strong candidates, especially where columns are consistent.
• Government statistics and data releases — often the highest-value case, because the underlying data is locked in PDF tables that were never published as data.
• Research papers — the body text is fine for PDF to Word, but data tables are dense and benefit from a page-level conversion.

If a document mixes narrative and tables — as annual reports do — the efficient strategy is to split the work: extract the tables here, and convert the text with the Word tool. One document, two tools, each doing the job it is good at.

Privacy and the data you are handling

Spreadsheet data is often the most sensitive material an organisation holds. A bank statement carries account numbers; a payroll export carries salaries; a client-billing table carries names and amounts. Uploading those to a random online converter is a real risk, not a theoretical one — free converters monetise uploaded content in ways their users rarely read about.

Extracting in the browser removes the risk entirely. The PDF is parsed on your machine, the spreadsheet is generated on your machine, and the only network requests are for the application's own static assets. You can confirm it by watching the Network tab during a conversion: your file never appears in an outbound request. For teams that work under GDPR or handle regulated data, this is not a nicety — it is the reason the tool is usable at all. Our security page summarises the posture, and the guide on converting PDFs privately goes deeper.

Turning extraction into a repeatable workflow

One-off conversions are useful; repeatable workflows are transformative. If you extract the same kind of document every month — a statement, a report, a supplier invoice — you can build a pipeline that turns an hour of typing into a few minutes of review.

The pattern looks like this:

1. Standardise the input — save the source pages into a consistent set of PDFs each cycle.
2. Extract with PDF to Excel in a batch.
3. Load the output into a template workbook with your formulas and charts already built.
4. Keep a reconciliation column and check totals against the source each cycle.
5. Archive the source and the extract together so every figure is traceable.

If you are building something more automated — an internal service that ingests PDFs and emits spreadsheets — the developers page describes the components and self-hosting options, and the documentation has the configuration details. For occasional use, the browser extension lets you right-click a linked PDF and extract it without downloading it first.

PDF to Excel versus other approaches

Extraction is not the only way to get data out of a PDF, and it is worth knowing the alternatives so you pick the right one.

• Manual retyping — zero setup, maximum error rate, and it gets slower every time. Avoid for anything recurring.
• Server-based converters — convenient but they upload your data; a poor trade for sensitive figures.
• PDF to Excel (in-browser) — fast, private, and accurate on conventional tables. The default recommendation for business documents.
• PDF to OCR — the necessary first step when the source is a scan; pair it with Excel extraction for scanned statements.
• PDF to Word — better when you need the narrative text rather than the numbers next to it.

For most analysts the practical answer is a small toolkit: OCR for scans, PDF to Excel for tables, and PDF to Word for prose. You can see all three on the tool box page, and each links to its own guide on the blog.

Frequently encountered edge cases

A few situations come up often enough to be worth calling out specifically.

Multi-page tables are handled by continuing the detected columns across pages, but a repeated header row on every page can appear multiple times in the output — delete the duplicates after extraction. Rotated tables, where a page is landscape inside a portrait document, occasionally confuse column detection; rotate the page upright before extracting. Tables that span a page break mid-row can produce a split row; stitch the halves back together. And tables whose cells contain line breaks produce multiline cells, which is correct, but can make the sheet look taller than expected.

None of these are blockers. They are the ordinary friction of turning pictures of data into real data, and they are all far cheaper to fix than retyping.

Getting started

The fastest way to judge any extraction tool is to run it on the document that annoys you most — the one you dread retyping every cycle. Convert it, review the high-risk rows, and see how close the output lands to what you would have typed by hand.

Data quality: numbers that stay numbers

The hidden difference between a merely exported sheet and a genuinely useful one is how faithfully it keeps types. It is the difference between being able to sum a column instantly and discovering every figure is stored as text that refuses to add up.

A well-built extractor writes numeric cells as Excel numbers, dates as dates, and amounts with the decimal and thousands separators respected. It also keeps leading zeros where they matter — invoice numbers like 000471 should stay 000471, not silently become 471. Two habits on your side of the desk protect this:

• Check the sheet has really kept types — a cell that sorts oddly or shows the green corner-flag for 'text that looks like a number' needs attention.
• Keep an eye on leading zeros and identifiers — sequence numbers and account codes are the values most often mangled by over-eager type coercion.

When a column comes out as text, the fix is usually a lightweight reformat in Excel rather than a re-extract. But if the pattern repeats, it is a signal the source document had inconsistent punctuation — a fix worth making at the source, not in the output.

Scaling: from one sheet to a whole library

Extraction stops being nice and becomes transformative when you stop doing it file-by-file and start treating it as a pipeline. The geometry is simple: a single conversion saves minutes, but a repeatable pipeline saves an afternoon every week.

For large or recurring work, three techniques matter most. First, standardise the input — the same kinds of pages from the same sources extract far more consistently than a grab-bag of formats. Second, batch rather than one-by-one, because the tool streams per-file results and keeps memory bounded. Third, verify a representative sample each cycle and weight it toward figures — a 99 percent accurate extraction is still a data-quality event if the 1 percent is a salary or a balance.

If you are connecting extraction to a system that consumes the workbooks — a reporting dashboard, an ERP load, an audit trail — the documentation covers the integration surface, and the developers page describes the building blocks if you want to drive extraction programmatically rather than through the browser UI.

When to bring in the data team

There is a point at which casual extraction becomes a team concern, and recognising it early avoids a costly redo. If you are extracting data that will be loaded into a governed system, audited, or shared across departments, treat the extraction as a minor data engineering job rather than a personal convenience.

That means agreeing on the source of truth, documenting the transformation, and building the reconciliation step into the routine. None of this requires heavy tooling — a named folder, a template workbook, and a verification check are usually enough. What it requires is the discipline to treat extracted data with the same care as data that was born in a database. Our PDF workflow for professionals guide shows exactly how to turn a loose habit into a repeatable, governed routine without over-engineering it.

Start your extraction habit

Start with the PDF to Excel tool. When you are ready to standardise the workflow, look at pricing for the plans that remove limits, grab the browser extension and Android app for one-click access, and browse the documentation if you want to wire extraction into something bigger. The blog has deeper guides on every neighbouring task.