PDF to Excel without uploading the file
Most converters work by uploading your PDF to a server. It is possible to do the whole thing in the browser instead — here is how that works and where it breaks.
What a converter actually does
Three steps, always the same:
- Get the text. Either from the PDF's text layer, or by rendering pages to images and running OCR.
- Group it. Text arrives as fragments with coordinates; you have to decide which fragments form a line, a cell, a column.
- Emit a spreadsheet. CSV is trivial; XLSX is a zip of XML files.
None of these steps needs a server. That is the whole trick.
Step 1 in the browser
PDF.js (the library inside Firefox's viewer) opens a PDF, and getTextContent() returns the text items with their positions. If the PDF was generated digitally, you now have exact text — no OCR, no errors.
The catch: items come back in drawing order, not reading order, and a whole page can arrive as one long line. Rebuild the lines yourself by grouping items whose vertical coordinate is the same. That single detail is the difference between "vendor: ACME Ltd" and "vendor: ACME Ltd Unit 4 Marsh Lane Bristol".
Step 2 is where converters fail
Grouping fragments into columns is the hard part. A table with merged cells, a column of numbers right-aligned against a column of labels, a two-column invoice layout — all of these produce nonsense if you guess wrong.
Practical rule: only attempt full table reconstruction when the PDF has a text layer and a consistent grid. Otherwise extract the fields you actually need (date, total, supplier) and let the human fill the rest. A converter that claims to handle every layout is either wrong or charging you for the correction step.
Step 3: XLSX in the browser
An .xlsx file is a ZIP containing XML. Libraries like SheetJS build it in a few lines, entirely client-side. The result opens in Excel, Numbers and Google Sheets. CSV is simpler still, but it loses types and column widths — which is exactly why people ask for Excel.
Where the browser approach breaks
- Huge files. A 300-page scan will exhaust memory where a server would queue it.
- Handwriting. Browser OCR models are small; handwriting needs big models.
- Complex tables. Layout analysis is where cloud services earn their money.
- Very slow machines. OCR is CPU-bound; a decade-old laptop will feel it.
How to check a converter's privacy claim
Open the developer tools, go to the Network tab, and convert a file. If the claim is true, no request will carry the document — you will see the OCR model download once, and nothing else. If you see a POST with your file in it, the claim is marketing.
This is a five-minute test and it is the only one that matters.
Common questions
Can a browser really read a PDF without a server?
Yes. PDF.js parses the file in JavaScript, and OCR runs in WebAssembly on your CPU. The only network activity is downloading the libraries themselves.
Is browser OCR as accurate as cloud OCR?
No. Cloud services use much larger models. Browser OCR is good on clean printed text and noticeably worse on photos, skew and faint print.
What about very large PDFs?
They are limited by your machine's memory. A few hundred scanned pages in one file will struggle; splitting the file is the practical fix.