From printed code to product record
The scanner uses the camera to read a standardized product identifier such as a UPC or EAN. An app then sends that identifier to its product-data source and retrieves a matching name, serving, and nutrient values when a record exists.
The code is a lookup key. It does not normally contain calories, protein, carbohydrate, or fat. That is why two apps can scan the same package yet show different data if their databases or record versions differ.
Why a barcode may return no result
- The product is new, regional, or from a small producer.
- The database has not received that code.
- Glare, damage, curve, or low contrast prevents the camera from reading it.
- A retailer printed an internal code rather than a standard consumer product code.
- The product was repackaged and the visible code identifies a case or bundle.
Verify product and serving
Match the brand, product name, flavor, package size, and serving unit to the item in your hand. Then compare the key numbers with the current Nutrition Facts panel. A correct product record can still create a wrong log if the app is set to one serving and you ate two.
FDA serving sizes are standardized to help comparison, but they are not a recommendation of how much any individual should eat.
Barcode and photo scanning solve different problems
Barcode lookup is strongest for an intact packaged item with a current label. Photo scanning is more flexible for plated or unpackaged food but must infer identity and portion. For a meal containing both, use the barcode for the packaged component and photo/manual review for the rest.