Why two apps show different calories for the same food
Two apps disagree because they are not looking at the same record. Six causes explain almost every gap: different underlying databases, duplicate entries for one product, per 100 g against per serving, raw against cooked weight, rounding plus the legal tolerance on labels, and plain user-submitted noise. None of them means one app is lying, and switching apps to find a friendlier number is the one response that reliably makes things worse.
A few percent to about 30.
Raw versus cooked weight.
One database, used consistently.
1. Different databases sit behind the search box
One app may resolve "chicken breast" to a laboratory entry from a national food composition table, another to a supermarket product label, a third to a user-created recipe entry. All three are legitimate answers to a vague question and they will differ, because a raw generic breast, a marinated retail pack and somebody's cooked leftovers are genuinely different foods. Vague searches produce disagreement; barcodes and specific products produce agreement.
2. The same product exists more than once
Duplicates are the reality of every barcode database, including this one. Dietly currently carries two entries for the same Wonderful sea salt and vinegar pistachios, transcribed from two labels: one records 11.2 g of carbohydrate per 100 g and the other 21.4 g, while their energy, protein and fat lines agree. Two entries for the same Trader Joe's crunchy peanut butter show the same pattern on sodium, 437.5 mg per 100 g in one and 0 mg in the other, where the second is a missing value rather than a salt-free jar. Missing is not zero, and that distinction moves numbers in every app that treats a blank field as a nought.
3. Per 100 g against per serving
An app that stores per-serving values and one that stores per 100 g values must convert, and conversions need a serving weight that is often absent or wrong. Anything expressed in cups, slices or pieces makes it worse. This is also how a food can appear to differ by exactly the ratio of its serving size, which is the giveaway: if two numbers differ by a clean factor like 1.09 or 0.7, you are looking at a serving-size problem rather than a data problem. The background is in portion size versus serving size and serving-size games.
4. Raw against cooked
This is the largest error most people ever make, and it is invisible. Meat loses roughly a quarter of its weight as water during cooking, so 100 g of raw chicken becomes about 75 g cooked with the same calories inside it. Rice and pasta go the other way, roughly tripling and doubling in weight as they absorb water. Log 100 g of cooked rice against a raw entry and you have overcounted by about 200 percent. Pick one convention, ideally raw and weighed before cooking, and keep it.
5. Rounding and the legal tolerance
Label values are rounded before they are printed, and official guidance allows a tolerance of roughly 20 percent for many nutrients, so two packs of the same product can carry different declared values without either being wrong. Databases inherit that spread. It is the reason chasing agreement to the calorie is futile, and the reason calorie labels are best treated as estimates.
6. Fibre, sugar alcohols and how carbohydrate is defined
European labels exclude fibre from the carbohydrate figure. United States labels include it, then list fibre separately underneath. The same food therefore has two different but equally correct carbohydrate numbers depending on which market its label was written for, which is where most net-carb confusion begins, as set out in what net carbs are. Sugar alcohols add a second layer, because they are counted at reduced energy values rather than the full 4 kcal per gram.
What to actually do
- Pick one database and stay in it. Consistency matters more than accuracy for tracking, because you are measuring change over time, not establishing the truth about an apple.
- Prefer entries with barcodes over generic text matches, and prefer entries that carry a full panel over ones with blanks.
- Weigh in grams, log raw where you can, and note your convention so future you does not switch it by accident.
- Treat blanks as unknown, not zero. A missing fibre or sodium field is missing.
- Judge the seven-day trend, not the day. A systematic 5 percent bias cancels out of a trend; it never cancels out of a single day.
If you want to see how two specific products differ rather than how two apps do, put them side by side in the comparison tool, which reads both from the same rows.
Bottom line
Different databases, duplicate records, serving conversions, raw against cooked, rounding and carbohydrate conventions explain nearly every disagreement you will meet. Any consistent database beats app-hopping, and where the numbers come from in the first place is set out in where nutrition data actually comes from.
Sources
Common questions
Why do two apps show different calories for the same food?
Usually because they resolve the food to different database entries, or convert between per 100 g and per serving differently. Raw versus cooked weight, label rounding, the legal tolerance and different carbohydrate conventions explain the rest.
Which nutrition app is the most accurate?
No app is authoritative, because all of them rest on the same declared and transcribed data. Consistency matters more than the specific source: pick one database, log by weight and judge the weekly trend.
Should I log food raw or cooked?
Raw and weighed before cooking is the more reliable convention, because cooking changes weight substantially. Meat loses around a quarter of its weight, while rice and pasta gain weight as they absorb water.
Why does the same product appear twice in a food database?
Because labels are transcribed from different packs, regions or years. Duplicate entries usually agree on energy and protein while differing on one line, often a field that was left blank on one of the two records.