Image to Excel: the Traps in Data From Picture

Two separate things have to go right here, and most guides only cover the first. Getting the digits off the image is the easy half. Getting them into a spreadsheet without Excel quietly rewriting them is where the actual damage happens.

Start with what Microsoft already gave you

If you have a Microsoft 365 subscription, Excel has a built-in reader. On Windows it is Data → From Picture, available from Version 2210 (Build 15723) onward, on Windows 10 version 1903 or later with the Edge WebView2 runtime installed. On iPhone and Android, the Excel app has had Insert data from picture for years and it works from the camera directly.

It is good at what it was built for: a printed table with visible rows and columns. It shows you the parsed grid, flags cells it is unsure about, and lets you correct them before inserting. For a bank statement or an invoice, try this first. It costs nothing and it is already installed.

Where it disappoints is anything that is not a table. A single long serial number, digits burned into a photograph, a seven-segment meter display, a screenshot of an app — the grid detector has nothing to grip, and you get either nothing or a mangled single column.

Google Sheets has no equivalent. The free workaround is Google Drive: upload the image, right-click it, choose Open with → Google Docs. Drive runs OCR into a document, and you copy from there.

The part that actually breaks: what Excel does to digits

This is where clean OCR output turns into wrong data, and it happens silently.

What you paste	What Excel does	Why
4532015112830366 (16 digits)	4532015112830000	Numbers hold 15 significant digits; the rest become zeros
007412	7412	Leading zeros are not significant in a number
356938035643809 (15 digits)	Survives, but shown as 3.56938E+14	Over 11 characters, Excel switches to scientific notation
12-3	12-Mar	Parsed as a date in most locales
1.234,56 from a European document	1.23456 or text	Decimal separator depends on your Windows locale

The 15-digit limit is the dangerous one, because it produces a plausible-looking number rather than an error. Excel stores values as double-precision floating point, which carries about 15 decimal digits of precision. A 16-digit card number, a 17-character VIN typed as digits, a long asset tag — the tail is replaced with zeros and nothing warns you.

The critical detail: formatting the column as Text afterwards does not bring the digits back. The precision was destroyed at the moment the cell was parsed. You have to set the format before the paste, or prefix each value with an apostrophe as you enter it. If you are importing a CSV, use Data → From Text/CSV and set the column type to Text in the preview, rather than double-clicking the file.

Nothing in this list is an OCR problem. You can read the digits perfectly and still end up with wrong data — and the quietest version of that is a number stored in the cell as text, which looks completely normal until a total comes back as zero.

Checking a column you did not type yourself

Once a few hundred values are in a sheet, you cannot eyeball them. Use structure instead.

Most of the numbers people extract in bulk have a fixed length. IMEIs are 15 digits. UK sort codes are 6. US ZIP codes are 5 or 9. A single formula finds every row that does not fit: =SUMPRODUCT(--(LEN(A2:A500)<>15)) returns a count of wrong-length entries in that range, and conditional formatting on the same LEN test highlights them.

Better still, use a check digit where one exists. An IMEI’s fifteenth digit is a Luhn checksum over the first fourteen, which means a single misread digit is arithmetically detectable — that is covered in finding an IMEI without the box. Bank card numbers use the same scheme. When your data has one of these, a validation column beats any amount of proofreading.

Length checks and check digits between them catch the errors that matter, because the common OCR confusions are substitutions rather than deletions. Why OCR gets numbers wrong walks through which characters get swapped for which, and it explains why a wrong digit almost never looks wrong.

When the image is not a table

For the single-value case — a serial off a label, a reference from a screenshot, a code you need exactly once — the round trip through Excel’s picture import is more work than the task deserves. Our number extraction tool is built for that shape of problem: drop the image, and it returns only the digit runs, in an editable field, so you can check them against the picture before they go anywhere.

Because it filters to numbers, it also skips the surrounding text that confuses a general recogniser — labels, units, currency symbols sitting against the figures. When what you want from a photograph is the digits and nothing else, the number extraction tool gets there faster than a grid parser trying to infer a table that was never there.

If you are working through a stack of physical labels rather than files on disk, capturing them with SwipeScan’s camera puts each value straight on the clipboard, which is less painful than photographing, transferring and importing each file. Doing that at the scale of a shelf has its own rules, in counting stock with a phone camera. There is no batch mode and no file export, so you are still pasting one at a time — the saving is in the transfer, not the volume.

Extracting a list of phone numbers has its own rules, since the format itself constrains what a valid answer can be — see pulling phone numbers out of a photo.

The short version

• Try Excel’s own Data → From Picture first if you have Microsoft 365; it is free and good at printed tables.
• Google Sheets has no equivalent; upload to Google Drive and open the image with Google Docs instead.
• Excel holds 15 significant digits. Longer numbers lose their tail to zeros, silently and permanently.
• Format columns as Text before pasting. Doing it afterwards does not restore anything.
• Validate in bulk with a LEN check, and with a check digit whenever the number has one.