Image Info Extractor — Bills, Receipts, Invoices, Screenshots

Two steps: read the pixels, then find the fields

This tool does 2 distinct jobs in sequence, and understanding the split explains everything about what it can and cannot do. Step 1 is Optical Character Recognition — turning the pixels of your image into a string of characters. That runs on Tesseract.js, a WebAssembly build of Tesseract — an engine Hewlett-Packard began in 1985 and Google open-sourced in 2006 — entirely inside your browser: it collapses the 3 RGB channels to 1 greyscale channel of 256 levels, applies Otsu adaptive thresholding to split ink from paper into 2 tones, segments the page into lines and words across typically 4 passes, and matches glyph shapes against the roughly 100 character classes in the model. Because it is compiled to WebAssembly and runs in a Web Worker, all of that happens on your own processor — the 1 English language model (roughly 10 to 15 MB) is fetched once and cached, and 0 image bytes are ever uploaded.

Step 2 is field extraction — taking that raw text and pulling out the 8 fields you actually want: date, total, tax, merchant, phone, email, reference number, and up to 8 line items. In browser mode this is done with pattern matching, a set of about 10 regular expressions that look for a label like Total or Goods and Services Tax and grab the amount beside it. That division matters because the 2 steps fail differently: a wrong character signals a step-1 OCR problem, while a correct value landing in the wrong 1 of 8 fields signals a step-2 extraction problem. The tool shows you both the structured summary and the raw OCR text precisely so you can tell which is which.

Why a field sometimes reads "Not found"

The most common disappointment: a total or invoice number plainly visible in the image yet comes back as "Not found" in the summary. Almost always the cause is step 2, not step 1: the value was read correctly but sat in 1 of countless layouts the ~10 patterns did not expect. Real receipts space their columns with runs of 6 to 12 whitespace characters — "Total: Rs 672.60" — and put words between the label and the value — "Invoice No: INV-2024-0091". A pattern that only allows 1 character between the label and the number will skip straight past both of those 2 layouts. This tool's matching was widened to tolerate arbitrary spacing and intervening words like "No" on the same line, so the 3 fields that most often broke — total, tax, and reference number — now resolve on a typical receipt. In one test capture the summary went from 3 fields found to 7 of 8 after this change alone.

A related trap is the tax field. On a line like "GST 18%: Rs 102.60" a naive pattern grabs the first number after GST and returns "18" — the 18% rate, not the 102.60 amount. The fix is to require a real money value: a currency symbol, or a number carrying exactly 2 decimal places. That 1 rule keeps a bare 18 from being mistaken for a rupee amount, and that is why the summary now reports the Rs 102.60 tax rather than the 18 rate — an 84.60 difference that would wreck any expense report. When a field still reads "Not found", scroll to the raw OCR text: if the value is there, the layout was simply outside the patterns, and AI Enhance is the fallback built for exactly that.

Browser mode versus AI Enhance, honestly

The 2 modes differ in 1 important way: where the text goes. Browser OCR keeps everything on your device; the pattern matching runs locally and nothing leaves. AI Enhance still reads the image locally — the picture itself never uploads — but it then sends the resulting OCR text to a third-party language model through OpenRouter (a Nemotron 9B model at temperature 0.2) to be cleaned up and reformatted. That is a genuine external network request, so the honest guidance is simple: do not use AI Enhance for text you would not paste into a chat window. A bill showing a 16-digit card number or your home address should stay in browser mode.

Be precise, too, about what AI Enhance produces. It does not return JSON or a database record; it returns the same plain-text labelled sections the browser mode uses, just tidied — noise removed, fields regrouped. It shines when a document's layout is chaotic enough that local pattern matching flails, for example a hotel folio with 30 or 40 line items in an irregular grid spanning 2 or 3 columns. Because it calls a paid service, it is capped at 3 requests every 20 minutes (a 1200-second window) with a 20,000 character input ceiling; browser mode has 0 such limits and handles the large majority of everyday receipts on its own.

Where this saves real time

The payoff is measured in minutes per document. Typing a 15-line receipt into a spreadsheet by hand takes 2 to 3 minutes and invites transcription slips; an OCR pass plus a 10-second cross-check against the raw text is closer to 30 seconds — a 4x to 6x speedup — and it scales: 50 receipts that would be a 2-hour data-entry session become a 25-minute review. The cross-check matters because OCR on a good image lands around 95 to 99% character accuracy, which sounds high until you remember a 4-digit total has 4 chances to be wrong; 1 misread digit in Rs 672.60 becoming Rs 612.60 is a 60-rupee error hiding in a plausible number. That is exactly why the tool prints the raw OCR text beside the 8 structured fields: you confirm the 2 or 3 numbers that matter in seconds rather than trusting a black box.

Getting the cleanest read

Since OCR quality caps everything downstream, the input is where accuracy is won or lost. Capture the document straight-on so text lines stay horizontal — even a 5 to 10 degree skew measurably degrades line segmentation, and past 15 degrees accuracy falls sharply. Fill 80 to 90% of the frame with the receipt rather than the desk around it, so more of the sensor's pixels land on actual text. Favour even, bright light: harsh side-lighting throws shadows that the black-and-white thresholding step misreads as strokes, and glare blows out whole numbers. A flat, well-lit 8-megapixel phone photo (about 3264x2448) of a printed receipt typically reads in 2 to 5 seconds and resolves 6 to 8 of the fields; a crumpled, dim, angled shot may need AI Enhance or a re-take. Digital screenshots, where the text is already pixel-perfect at 100% zoom, are the easiest input of all — often 99% accurate in under 2 seconds.

Quick reference

• OCR engine: Tesseract.js (WebAssembly), 1 English model of 10 to 15 MB, in a Web Worker.
• Fields: 8 total — date, total, tax, merchant, phone, email, reference number, and up to 8 line items.
• Browser mode: 100% local, free, 0 request limit; image never uploaded.
• AI Enhance: sends OCR text (not the image) to OpenRouter; 3 runs per 20 minutes, 20,000-char cap.
• AI output: plain-text labelled sections, not JSON.
• Amount rule: a value counts as money only with a currency symbol or 2 decimals (so "18%" is not read as an amount).
• Accuracy: about 95 to 99% on clean printed text; under 50% on handwriting.
• Best input: flat, sharp, well-lit printed text or a digital screenshot.
• Weak cases: handwriting, decorative fonts, non-English scripts, skew past 15 degrees.
• Verify: the raw OCR text is shown below the summary — always cross-check.