Last reviewed: July 2026

How food barcodes work, and what they do not contain

A barcode on a food package contains no nutrition information at all. It carries one thing: a number that identifies the product, usually 13 digits for EAN-13 or 12 for UPC-A. Everything else, the calories, the ingredients, the allergens, the picture, comes from a database that someone built by mapping that number to a product. When a scanning app tells you a food has 431 kcal per 100 g, the barcode found the record; it did not carry it.

What the 13 digits actually mean

An EAN-13 code breaks into three parts. The first two or three digits are a GS1 prefix, which identifies the GS1 member organisation that issued the number. The next block is the company prefix, assigned to the brand owner and variable in length. The remaining digits before the last are the item reference, chosen by the company itself. The final digit is a check digit derived from the twelve before it.

Take the code printed on a real entry in this database, the Kashi Vanilla Almond cereal at 0018627115304. The leading zero marks it as a 12-digit UPC-A code stored in 13-digit form, the prefix range belongs to GS1 US, the middle block belongs to the brand owner, and the trailing 4 is the check digit. The same structure holds for the Fiber One brownies at 0016000408036 and the Wonderful pistachios at 0014113700368.

The check digit, worked through

The check digit exists so that a misread scan fails loudly instead of returning the wrong product. It is computed by weighting the first twelve digits alternately by 1 and 3, summing them, and taking whatever is needed to reach the next multiple of ten.

The printed code ends in 4, so the scan is valid. Change any single digit and the arithmetic breaks, which is exactly the point. It catches single-digit errors always and most transpositions, though not all of them.

The country prefix is not where the food was made

This is the internet's favourite barcode myth. The prefix identifies the GS1 organisation that issued the company its number, not the origin of the product or even the nationality of the company. Prefixes 00 to 13 belong to GS1 US, 30 to 37 to France, 400 to 440 to Germany, 500 to 509 to the United Kingdom, 87 to the Netherlands, 690 to 699 to China. A Dutch company can hold a US-issued prefix, and a product with a German prefix can be manufactured anywhere on earth. Origin is a labelling matter, printed in words on the pack, and it is not encoded in the bars.

The formats you will meet

• EAN-13. The global default on retail packs, 13 digits.
• UPC-A. The 12-digit North American format. It is really an EAN-13 with a leading zero, which is why databases usually store it padded to 13 digits.
• EAN-8. A short form for packs too small for a full code, such as single confectionery bars and spice jars.
• GTIN-14 and ITF-14. Used on outer cases and trade units rather than consumer packs, with an extra leading digit indicating packaging level.
• 2D codes. GS1 is pushing retailers to accept QR-style codes at checkout, which can carry a batch number, an expiry date and a link as well as the identifier. Expect both symbologies on packs for years.

Loose fruit and vegetables use a different system entirely. Those four or five digit PLU stickers are not GS1 codes, and a leading 9 conventionally marks organic produce, which is why an organic apple and a conventional one ring up differently at a self-checkout.

Why a valid scan still returns "not found"

Most barcode lookup failures are not missing products, they are format mismatches. A phone camera library may report a UPC-A as 12 digits while the database stores the same product zero-padded to 13. A warehouse scanner may report a GTIN-14 with an extra leading digit. Zero padding never changes which product a number names, so a lookup that compares the scanned string literally will return nothing for a code it actually holds.

The fix, for anyone building this, is to try the equivalent forms in order rather than failing on the first miss: the literal scan, then the 13-digit zero-padded form, then the 14-digit form, then the form with a leading zero stripped. It is worth rejecting all-zero codes outright, because scanners emit them as noise and every database contains a few junk rows that would otherwise match. The Dietly barcode endpoint accepts both EAN-13 and UPC-A for exactly this reason.

What a barcode still cannot tell you

It cannot tell you nutrition, ingredients, allergens, price, weight, batch or expiry date. It cannot tell you whether the recipe changed last month, which is why a database can be confidently wrong about a reformulated product. It cannot even guarantee that a code is unique forever, since numbers are occasionally reassigned after a product is discontinued. All a scan gives you is a key, and the quality of what comes back depends entirely on the catalogue behind it, which is set out in where nutrition data actually comes from. Two apps scanning the same pack can still disagree, for reasons that have nothing to do with the barcode.

Bottom line

Thirteen digits, three meaningful blocks and a check digit that makes bad scans fail rather than lie. The prefix names the issuing organisation, not the country of manufacture, and the code carries no nutrition data whatsoever. Everything you see after a scan came from a database, so the interesting question is never the barcode, it is the catalogue behind it.