Scanning food barcodes with the camera you already have

The formats on food packaging

Retail food carries one of a small, fixed set of symbologies. EAN-13 is the thirteen-digit code used across Europe. EAN-8 is the short one on packs too small for thirteen digits. UPC-A is the twelve-digit North American equivalent, and UPC-E is a compressed eight-digit form of it. ITF-14 appears on outer cases rather than consumer packs.

A scanner only needs those. The last digit of an EAN or UPC code is a check digit calculated from the others, which is a quietly important detail: a misread or a mistyped number nearly always fails that checksum instead of silently matching some other product. A scanner that validates the check digit is one that will not confidently show you the calories of the wrong food.

When the camera will not catch it

In rough order of how often it is the cause: too little light, so the bars have no contrast; a curved surface, which bends the bars apart — a tin or a bottle usually scans at the flattest part, or rotated so the bars run across the curve rather than along it; too close, which is the most common mistake, since the whole code including the pale margin either side has to fit in frame; a crinkled film pack, which can need flattening with a thumb; and a glossy wrapper reflecting a ceiling light straight back, which moving a few degrees fixes.

If none of that works within a few seconds, stop fighting it. The digits are printed under the bars for exactly this situation.

iPhone and Android do not scan the same way

Chromium-based browsers — Chrome on Android and on the desktop, Edge, and the rest — expose a barcode reader a web page can use directly. It is fast, and there is nothing to download.

Safari does not have that API, so a page that wants to scan on an iPhone has to bring its own decoder compiled to WebAssembly. That works well; it just downloads once, which is why the first scan on an iPhone can take a moment longer than the ones after it. Either way the decoding happens on the device: the camera frames are read and discarded on the phone, and a scanner has no reason to upload a picture of your hand holding a tin.

One thing is the same everywhere: a browser only hands over the camera on a secure connection, and it will ask permission the first time. Declining it does not have to be the end — a decent scanner still takes the number by hand.

The number works just as well

Typing thirteen digits sounds slower than scanning, and for one product it is barely slower at all. It also works where the camera cannot: no camera on the device, permission declined, a damaged label, a dark cupboard.

And it has one advantage worth knowing. The check digit means a typo is almost always caught immediately rather than quietly returning a different food. If a number is rejected, re-read the last digit before re-reading the rest.

What the scan can and cannot tell you

A barcode is a product number. Everything else — the name, the brand, the pack size, the per-100 g figures — comes from whatever database the number is looked up in, usually Open Food Facts for packaged food. So the quality of a scan is really the quality of a record somebody typed in, and the honest thing for a scanner to do is say which database answered and when that record was last edited.

Food with no barcode is a different question with a different source: USDA FoodData Central, which is public domain, covers generic items — raw meat, vegetables, milk by the glass — that no packaging ever carried a code for.