How the comparison works
Each value is divided by its serving weight and multiplied by 100. This puts the label and database record on the same per-100g basis.
The percentage difference uses the label as the reference: database value minus label value, divided by the label value.
Read the result as a diagnostic
If every normalized value aligns, the original records mainly differed in serving size. If one or more values still differ, compare the exact product, flavor, preparation state, unit, and label date.
Matching calories do not prove the entire entry matches. Check the macros and description too. Small label differences can also come from rounding.
Check the context before correcting an entry
For a packaged product, use the current label on the package you have. For an unlabeled whole food, use a documented reference such as USDA FoodData Central and match raw or cooked state, edible portion, and food description.
The food database entry guide provides the complete verification order. If you need to scale one verified label to your portion, use the serving size calculator.
Why database entries go wrong in the first place
Most calorie apps run on databases that are partly or wholly user-submitted, and nobody checks each entry. The common failure modes are worth recognising by sight:
- The wrong region. The same brand sells different recipes in different countries, and an entry created in one market can be attached to a barcode sold in another.
- A stale recipe. Manufacturers reformulate. An entry created three years ago may be accurate for a product that no longer exists.
- A serving-size mismatch. The most common one by far. The numbers are right for a serving that is not the serving on your pack, which is exactly what the calculator above normalises away.
- Cooked entered as raw, or the reverse. Especially for meat, rice and pasta, where the two states differ enormously.
- Someone typed it wrong. A decimal point in the wrong place survives in these databases for years.
Spotting a bad entry in a few seconds
Before comparing anything, some entries can be dismissed on sight:
- Suspiciously round numbers. A real label rarely reads exactly 200 calories, 20g protein, 20g carbs, 10g fat. That pattern usually means someone estimated.
- Missing macros. An entry with calories but no protein, carbohydrate or fat is a guess, not a transcription.
- Macros that do not add up. Multiply protein and carbohydrate by 4, fat by 9, and add them. If that total is far from the stated calories, something is wrong. The macro calorie calculator does this check, and its factor table explains the cases where a genuine gap is expected, such as fibre and polyols.
- No brand or a vague name. "Chicken breast" is a generic reference value. "Brand X chicken breast, raw" is a label transcription. Prefer the second when you have the pack.
What to do when they disagree
If you have the packet in front of you, the packet wins. It describes the product you are actually eating, and a database entry never can. Enter the label values as a custom food and use that from then on.
If you do not have the packet, prefer an entry that names the brand and the preparation state over a generic one, and expect an unbranded entry to be a reasonable average rather than a match. For a meal you eat repeatedly, weighing it once and saving the result removes the question permanently; the weighed repeat meal calculator is built for that.
One thing not to do is switch entries until you find the lowest one. That is a way of choosing the number you prefer rather than the number that is true, and it makes the log less useful to review later.
The comparison stays in your browser
The values are calculated on this page. They are not uploaded by this tool, and no sign-in is required. Refreshing or closing the page clears the entered values.