Every receipt scanner I looked at uploaded the image to a server to read it. That makes sense technically. It made no sense to me otherwise.
A year of receipts is a fairly complete picture of a person. Which pharmacy you use. Which bar. Whether you hired a lawyer. Where you were on a Tuesday night in March. Most of them carry the last four of your card across the bottom. I did not want mine sitting on someone else's disk, and I did not want to explain to anyone else why they should be comfortable with theirs.
So I tried to do the whole thing in the browser. No server, no upload, no account. Here is what that actually cost.
Tesseract.js is the easy part and the slow part
The OCR itself is tesseract.js, loaded from a CDN. Getting text out of an image is about ten lines.
The cost is weight and time. You are shipping a WASM build and a trained language model to the browser before anything happens. On a desktop with a warm cache it is fine. On a phone, on mobile data, the first run is noticeably slower than anyone expects from a web page.
The mitigation is boring but it works: load the libraries once at page load rather than on demand, and let the browser cache do the rest. After the first visit the tool runs offline. That is a nice property to have accidentally.
A digital PDF receipt reads essentially instantly, because there is real text in the file and no OCR is needed at all. A phone photo of a printed receipt takes a few seconds. A bad photo takes longer and returns worse text.
Faded thermal paper defeats it completely
This is the part I would tell anyone building in this space first.
Thermal receipts do not use ink. They use a heat sensitive dye that keeps reacting after you leave the store. Heat accelerates it, so does sunlight, so does the plastic in a wallet. A gas receipt that spent a summer in a glovebox is often blank by spring. Not faint. Blank.
No OCR engine recovers that, because there is nothing left to recover. Mine does not either.
The design question is what you do about it, and I think this is where most tools get it wrong. The tempting behaviour is to return a best guess and let it look like a successful read. That is worse than failing, because the user has no signal that a number in their spreadsheet is fiction.
So the row stays on the sheet, flagged, with the total left empty. The footer says something like "3 of 4 read, 1 needs a total." You type the missing one yourself.
It makes the product look less capable in a demo. It makes it trustworthy in use. Given the output ends up in a tax return, that is not a close call.
Parsing is the part nobody writes about
OCR gives you a blob of text. Turning that into date, vendor, total, tax is where most of the actual work lives, and it is unglamorous.
Some of the problems:
Totals are not labelled consistently. TOTAL, AMOUNT DUE, BALANCE, or nothing at all. Sometimes the largest number on the receipt is the total. Sometimes it is the cash tendered.
Dates come in every format a point of sale system has ever emitted, and OCR will happily turn a 0 into an O or an 8 into a B.
The vendor name is usually the first line, except when the first line is a slogan, a store number, or an address.
Tax lines look like totals.
There is no clever solution here. It is heuristics, tested against a pile of real receipts, adjusted when something breaks. Anyone claiming otherwise is either using a hosted service or has not tried enough receipts.
Generating xlsx on the client
Originally I used SheetJS. It writes a valid workbook, it is well documented, and the community build is free.
What the community build will not do is cell styling. No bold headers, no fills, no borders. You can set column widths, number formats and autofilter, and that is where it stops.
For a while that was fine. Then I looked at the output the way a user would and it was a grid of unformatted text with 18.4 in a column that should read $18.40. Technically correct, and it looked like a data dump rather than something you hand to an accountant.
I swapped to ExcelJS. It is roughly the same payload, it supports real styling, and it took an afternoon. Now the export has a header row, banded rows, currency formatting, a frozen header, an autofilter, and a second sheet with totals by category.
One detail worth passing on: write dates as real Date objects with a numFmt, not as strings. Text dates sort alphabetically, which means 01/05 sorts before 12/31/2025. If your output is someone's year of expenses, that quietly corrupts their ordering.
And parse YYYY-MM-DD into a local date rather than letting the default constructor treat it as UTC, or every date renders a day early for anyone west of Greenwich.
Shipping as a single HTML file
The whole thing is one HTML file. Style inlined, script inlined, libraries from a CDN. You download it, double click it, and it runs.
What that buys:
The privacy claim is checkable. Anyone can open the file in a text editor and read what it does. Anyone can run it with the network tab open and watch nothing leave. That is a stronger statement than a privacy policy, because it does not require trusting me.
It works offline after first load.
There is no backend to secure, no database to breach, no account system to get wrong, and no subscription to cancel.
What it costs:
No sync, no multi-device, no server-side processing for anything heavy. Every constraint of the browser is your constraint.
The file must stay small enough to be readable by a human who wants to check it, which rules out a lot of convenient dependencies.
The part I would do the same way again
Everything runs locally, which means you can verify it rather than believe it. Open devtools, watch the network tab, drop a receipt in. Nothing goes out.
That is not a policy. It is just how it is built, and it is the only version of a privacy claim I would be comfortable making.
I build DropSheet, which is the tool described above. It converts receipt photos and PDFs into a spreadsheet, entirely in the browser.
