The recognition engine runs inside the page, not on a server. Here is how it works, what it was measured at, and where it stops.
Quick answer:
The recognition engine is compiled to WebAssembly and runs inside the page, so your document is opened, rendered, recognised and converted entirely by your own browser — one network request, for the ~6 MB engine, then cached. Recognised words come back with a box around each, which is the same shape of information a normal PDF gives for its characters, so they go through exactly the same column-finding code. The small English model is used deliberately: 2.95 MB against 10.9 MB, with identical measured results. Open the table extractor and tick Read scanned pages (OCR).
Does the OCR run on a server?
No. The engine is WebAssembly running inside the page, so your document is opened, rendered, recognised and converted by your own browser. Adobe, Smallpdf and OnlineOCR all upload the file to do this.
How do recognised words become columns?
Each word comes back with a box around it — the same shape of information a normal PDF gives for its characters — so they go through exactly the same column-finding code. There is no separate OCR table mode.
Which model does it use?
Tesseract, with the small English model — 2.95 MB against 10.9 MB, despite names suggesting the reverse. Measured on every scanned table here, the two gave identical results.
Why are low-confidence cells not highlighted?
Because the scores do not separate. Words read wrongly averaged 84 and words read correctly averaged 89. A threshold at 70 catches a quarter of the errors while flagging a dozen good words.
Is it free, and is there a page limit?
Yes, free — no page limit, no account, no watermark. There is nothing to meter because the work runs on your machine. The one cost is a ~6 MB engine download, once.
Recognition runs on your device. No account, no upload.
OCR that runs in the browser, and why that is unusual
Optical character recognition used to mean a server. Every well-known PDF-to-Excel service with an OCR option — Adobe, Smallpdf, OnlineOCR, the PDFxlsx family — takes your document, sends it to a machine you do not control, recognises it there and sends a spreadsheet back. That is a reasonable engineering decision and it is why they all work the same way.
It is also why a great many people never convert the document they actually have. Payroll, medical records, client statements, contracts under NDA — the file cannot be uploaded, so the job gets done by hand or not at all.
This runs the recognition engine inside the page, compiled to WebAssembly. The document is opened by your browser, rendered by your browser, recognised by your browser, and the spreadsheet is built by your browser. One network request happens: fetching the engine itself, about 6 MB, which is then cached so the second document costs nothing. You can watch all of this in the Network tab — no request carries your file, because there is no code on the page that would send one.
The recognised words become table cells without a second guess
Worth spelling out, because it is where OCR-to-spreadsheet tools usually go wrong. A recogniser does not return a wall of text: it returns each word with a box around it — a position and a size on the page.
That is the same shape of information a normal PDF hands over for its characters. So the recognised words are mapped into that shape and given to exactly the same column-finding code a text PDF goes through. There is no separate "OCR table mode" with its own idea of where a column is, and therefore no second implementation to disagree with the first. A scanned table and a typed table are laid out by one routine.
Two details in that mapping that are easy to get wrong and both measured:
The vertical axis is upside down between the two worlds. A recogniser counts downward from the top of the image; the PDF world counts upward from the bottom of the page. Skip the flip and the table arrives in reverse row order — which looks plausible enough on a price list to escape a glance.
Rows are grouped on the BOTTOM of each word box, because that approximates the baseline the line was typed on. Group on the top edge instead and a single printed line splits into two rows whenever a word has no descender, which happens constantly.
The engine, and a model name that means the opposite of what it says
Recognition uses Tesseract, the long-established open-source engine, in its WebAssembly build. Language data is a separate download from the program, and there are two English models available.
Their names invite the wrong choice. 4.0.0_best_int sounds like the compromise and 4.0.0 sounds like the full one. In download size it is the reverse: 2.95 MB against 10.9 MB. We measured both on every scanned table in the project, and the results were identical — same cells, same numeric cells, same timings to within noise:
Page
Small model — figures exact
Large model — figures exact
7-row, 150 dpi
13 of 14
13 of 14
30-row, 150 dpi
60 of 60
60 of 60
30-row, rough 82 dpi
53 of 60
53 of 60
So the small one is used, deliberately and by size rather than by name. Four times the download for no measurable gain is a cost paid by every visitor on a phone.
How big to render the page before recognising it
A recogniser reads pixels, so the page has to be drawn at some size first, and that choice matters more than it sounds. Too small and the strokes blur together; too large and the engine slows down and — this is the part that surprises people — accuracy can fall again.
Render scale
Width in pixels
Cells exactly right
Time
1×
612
91%
523 ms
1.5×
918
94%
900 ms
2×
1224
97%
1129 ms
2.1×
1286
100%
1311 ms
3×
1836
100%
1604 ms
4×
2448
97%
1874 ms
The curve peaks and comes back down: 100% at 2.1× and 3×, but 97% at 4×, for nearly four times the work. Enlarging past the detail the scan actually contains does not invent detail — it magnifies the blur. The shipped setting sits on that plateau, with the long side capped so a large page on a phone does not exhaust its memory.
Why there is no confidence highlight, though every OCR engine offers one
Tesseract reports a confidence score for every word, and shading the low-confidence ones is the obvious feature. We built it, measured it, and did not ship it — and since it is the first thing anyone asks for, here is the measurement.
Across our scans the words it read wrongly averaged 84. The words it read correctly averaged 89. Five points apart, on overlapping distributions — there is no threshold that separates them:
Threshold
Real mistakes caught (of 36)
Correct words wrongly flagged (of 104)
Below 60
8
8
Below 70
25
12
Below 80
28
15
Below 90
36
28
Read the middle rows: at 70 you catch a quarter of the errors and accuse a dozen good words. A highlight that misses three-quarters of the mistakes is worse than none at all, because you would come to rely on the unshaded cells being right.
What ships instead asks a question the score cannot: can this cell be what its column is? A column of money holding 12O0.00 — a capital O among the digits — is not a hesitant reading, it is an impossible one. That check flagged 6 of 6 deliberately corrupted figures with no false alarms, and raised nothing on 6 correctly extracted typed pages. It only sees about one OCR error in five, because the rest are in description text where there is nothing to check against — and the page says so rather than letting you assume otherwise.
The honest limits of this route
English only. Each additional language is another data download, and none of the others has been measured here. A page in another language will be recognised badly rather than refused, which is the failure mode to watch for.
Handwriting, no. This engine is built for printed characters. A handwritten ledger is out of reach — not badly recognised, effectively unreadable.
It is seconds per page, not instant, because the work happens on your device rather than on a rack of servers. A long document is a wait. The button becomes a Cancel while it runs, and pages already read are kept.
A scanned ruled table gains nothing from its rules, because they are pixels rather than vector paths by then. The columns come from the spacing instead.
The engine download is about 6 MB, once, then cached by your browser. On a metered connection that is a real cost and it is better stated than discovered.
Where to go next
Scanned PDF to Excel — the practical side of the same thing — what quality costs, and the scanner settings that decide it.
Image to Excel — recognition applied to a screenshot or picture rather than a PDF page.
PDF table extractor — what happens after recognition: how recognised words become rows and columns.
Frequently Asked Questions
This one. The recognition engine is compiled to WebAssembly and runs inside the page, so your document is opened, rendered, recognised and converted entirely by your own browser. The only network request is for the engine itself, about 6 MB the first time, which is then cached. Adobe, Smallpdf and OnlineOCR all send your document to their servers to do this.
The recogniser does not return a wall of text — it returns each word with a box around it, which is a position and a size on the page. That is the same shape of information a normal PDF gives for its characters, so the recognised words are handed to exactly the same column-finding code a text PDF goes through. There is no separate OCR table mode with its own idea of where a column is.
Tesseract, in its WebAssembly build, with the small English model — 2.95 MB rather than 10.9 MB. The names suggest the opposite trade, so it is chosen by size rather than by name. We measured both on every scanned table in the project and the results were identical: on a 30-row statement at 150 dpi both gave 60 of 60 money figures exactly right. Four times the download for no measurable gain is a cost every visitor on a phone would pay.
Up to a point, then it reverses. Measured across a sweep: 91% of cells exact at 1×, 100% at 2.1× and 3×, and back down to 97% at 4× for nearly four times the work. Enlarging past the detail the scan actually contains magnifies the blur rather than inventing detail. The shipped setting sits on that plateau.
Because we measured it and the scores do not separate. Words read wrongly averaged 84 and words read correctly averaged 89 — five points apart on overlapping distributions. A threshold at 70 catches 25 of 36 real mistakes while flagging 12 good words. A highlight that misses three-quarters of the errors is worse than none, because you would trust the unshaded cells.
A cell that cannot be what its column is. A column of money holding 12O0.00 — a capital O among the digits — is not a hesitant reading, it is an impossible one. That check flagged 6 of 6 deliberately corrupted figures with no false alarms and raised nothing on 6 correctly extracted typed pages. It catches roughly one OCR error in five; the rest are in description text where there is nothing to check against.
No to handwriting — this engine is built for printed characters, and a handwritten ledger is effectively unreadable rather than badly read. English only for now: each additional language is another data download and none of the others has been measured here. A page in another language will be recognised badly rather than refused, which is the thing to watch for.
Because the work happens on your device rather than on a rack of servers, so it is seconds per page. The button becomes a Cancel while it runs and pages already read are kept. That is the trade: the document stays with you, and you wait a little.
Free, with no page limit, no account and no watermark. There is nothing to meter, because the work happens on your machine rather than on ours — the usual free-tier caps exist to limit somebody's server bill, and there is no server bill here. The only cost is the one-off engine download of about 6 MB.
No. The recognition engine is WebAssembly fetched by the page and run by the browser, so there is no application, no runtime, no Python and no command line. That is the practical difference from the library route — Camelot, Tabula and pdfplumber are all better for a scripted pipeline and all require an installation first.
Once the page and the engine have loaded, the conversion itself needs no network — everything runs locally, and you can put the device into aeroplane mode mid-conversion without breaking it. You do need a connection to load the page and to fetch the engine the first time. Nothing is kept for later use on purpose: no service worker holds a copy of this site, so a fix we ship reaches you rather than sitting behind a stale cache.
Yes, and a scan gives it no choice. Ruling lines in a software-generated PDF are vector paths that can be read exactly, but in a scan they are just dark pixels, so every recognised table is laid out from the gaps between words instead. That method handles left-aligned labels and right-aligned figures identically, which is most of what a table is.
Because a digit is a small shape and several of them are nearly the same shape. The classic confusions are 0 with O, 1 with l and I, 5 with S, and 8 with B — and in a money column the result is a well-formed number that is simply not the right one. A cell that cannot be what its column is gets flagged, but a misread that produces a plausible figure cannot be caught by looking at the cell alone.
For the structure, yes. For the figures, not without checking — and no OCR from any vendor is. Treat a recognised statement as a draft to verify rather than a source of record, check the totals against what the document printed, and keep the original. Where the document has a running balance, Financial extraction checks the arithmetic of the whole document, which is the one test that can see a misread digit at all.