Why two calorie apps disagree about the same food

Two apps, one food, two numbers

You log the same yogurt in two trackers and get two answers. The obvious conclusion is that one of them is broken, and the obvious next move is to go looking for the accurate one.

Both instincts are wrong, and the reason is worth ten minutes of your time, because it changes what you do about it.

Between the food in your hand and the number on your screen there are four decisions. Which database entry the app picked. Which energy factors that database used. How the printed figure was rounded before anybody read it. And whether the number came from a lookup at all, or from something guessing. None of those four is a measurement of your yogurt. Every one of them is a legitimate choice, and two honest apps can make them differently.

The multiplier is a choice

Start with the one almost nobody mentions, because it is the cleanest.

Calories are not measured in a food, they are calculated from it. You measure the protein, fat and carbohydrate, then multiply each by a factor and add. The famous factors are 4 for protein, 9 for fat, 4 for carbohydrate — those are the Atwater general factors, and they are an average across all foods.

But there is a second set. Atwater also derived food-specific factors, because a gram of fat in a bottle of oil is not digested quite like a gram of fat in a piece of cheese. USDA publishes both, and says so plainly:

Read that again, because it is the whole section. The same food card can carry two different calorie figures, both from USDA, both correct. An app that ingests FoodData Central has to pick one. Two apps can pick differently and both truthfully say “our data comes from USDA”.

How far apart? Cooking oil is the cleanest case, because it is a single ingredient and the arithmetic is short:

Nobody measured the carbohydrate

Here is the second thing that will change how you read a nutrition panel.

Water, protein, fat and ash are each measured in a laboratory. Carbohydrate usually is not. It is what is left over:

Which means every small error in those four measurements ends up inside the carbohydrate figure, with its sign flipped — and then gets multiplied by four on its way into the calorie total. Two laboratories analysing the same loaf will differ slightly on moisture, and that difference arrives in your app as calories.

It also means the carbohydrate line quietly contains things that are not really carbohydrate. This is not sloppiness; it is the accepted method, used by USDA and permitted for labels. It is simply not the measurement most people assume it is.

The label is a legal band, not a measurement

Now the packet itself. The number printed on it is not what a laboratory found. It is that number pushed into a legal grid.

Calories round in steps

Under US labeling rules a figure under five calories may be declared as zero, and everything above rounds in five-calorie steps up to fifty, then ten-calorie steps. Which is why you have never seen a packet claim 107 calories. It is not a style choice; 107 is not a legal thing to print.

The consequence people miss: when an app divides a rounded serving figure by the serving weight to get a per-100 g value, the rounding allowance is divided along with it and then multiplied back up by your portion. A five-calorie allowance on a 30 g serving is about 17 calories once it reaches 100 g, and more again on a plateful. The calculator below does this on your own packet.

The macros round too, and differently

Fat, carbohydrate, fiber and protein round to the nearest half gram below five grams, to the nearest gram from five to fifty, and to the nearest five grams above that. Anything under half a gram may be printed as zero.

So the grams beside the calories were each rounded independently, while the calorie figure was rounded on its own scale. Multiplying the printed grams by 4, 4 and 9 and expecting the printed calories to come back is asking two different rounding systems to agree. They usually do not, and neither is wrong.

And the tolerance is one-sided

This is the part that surprises people, and it is worth stating carefully because the popular version of it is wrong.

It is not a ±20% window. The rules are asymmetric, and they run in the direction that protects the consumer:

So a bar printed as 200 calories can hold rather more than 200 and still comply. It is not a loophole anybody is exploiting — food varies, batches vary, and a regulation has to allow for that. But it does mean the packet is a band, and your app inherited the band without being told.

Work out the band on your own label

Four numbers off the packet in your hand. Nothing is stored, and no account is needed.

“We use USDA data” is not an answer

Nearly every tracker says it. It narrows things down less than it sounds, because FoodData Central is not one database — it is several, maintained on different schedules for different purposes.

• Foundation Foods — individually sampled and analysed, with the sampling detail published alongside. The most transparent, and the smallest.
• SR Legacy — the old Standard Reference, enormous and widely used, and frozen. It is a historical release, not a living one.
• FNDDS — built for national dietary surveys, including prepared and mixed dishes.
• Branded Foods — label data supplied by industry. Which is worth pausing on: these are transcribed packets. If a manufacturer calculated its own label from a database in the first place, then “the database says X, the label says Y” is two databases disagreeing, not truth against a copy.

Two apps can both use FoodData Central, draw from different data types within it, take different energy fields, and land several percent apart without either doing anything questionable.

The entry each app picked

This is the explanation everyone else gives, so we will be quick: it is real, and it is not the whole story.

Databases that accept user-created entries accumulate whatever was typed into them, and a wrong entry does not expire. Some products keep staff-reviewed entries alongside; some mark verified records; some do neither. If you search a common food and get eleven results with eleven numbers, that is what you are seeing.

Two boring cases cause more damage than the exotic ones. Raw against cooked is the biggest: dry rice and cooked rice are different entries for the same rice, and mixing them is a large error rather than a small one — the finished-weight method exists partly to keep them straight. And per serving against per 100 g: pick the wrong one and you are wrong by whatever the serving happens to be.

A posted restaurant figure is a third kind of number again — not a database row and not a model's guess, but a measurement somebody else made once. Counting calories eating out covers how far to trust it.

A photograph is not a lookup at all

When you search a food by name, something looks it up in a table, and you can go and check that table. When you photograph a plate, that step does not happen. A model produces the figures directly.

These are not two attempts at the same job with one winner. A database entry carries the uncertainty which row; a photograph carries the uncertainty how many grams are on that plate. They are different species of guess, which is why comparing them and declaring one accurate misses the point. We wrote up what a photo estimate can and cannot see separately.

What our own app does, since we are one of them

It would be a poor page that explained all this and then went quiet about itself.

• Search goes through three tiers, in order: our built-in list, USDA FoodData Central, then Open Food Facts — the two external tiers are only queried when the built-in list returns too little. One consequence you should know: the same search can return a different set of rows within the same day, because the external tiers run under a time budget and drop out when they are slow.
• The photo path performs no food database lookup at all. The model produces the per-100 g figures itself. That is the honest description, and it is the reason a photo estimate is an estimate.
• Everything we store is grams. Not cups, not spoons, not servings.
• We publish no accuracy percentage, for the reason set out on our accuracy page: we have not run a protocol that would justify one, and a number without a protocol is marketing.

None of that makes us the accurate app. It makes us an app whose sources you can name, which is a different and more checkable claim.

So which number do you log?

Here is the part that pays for the reading, and it turns on a distinction almost no one makes.

A bias that never changes is nearly harmless. One that lands somewhere different every day is not. If you always pick the same entry for your usual breakfast and it reads eight percent high, breakfast is eight percent high every morning — and the change from one week to the next, which is the thing you actually act on, is untouched by it. Pick a different entry each morning and that stability is gone: the week-to-week change now carries the scatter as well as the food. Which way an error leans matters too, and what a lean costs against a wobble is worked out in calories on the sister page.

1. Pick a source and stay in it. Whichever app, whichever entry — the sticking matters more than the picking.
2. Reuse the same entry rather than re-searching. Re-searching a repeated food is how the inconsistency gets in.
3. Read the packet, not the app, for packaged food. It is closer to the thing in your hand, band and all.
4. Do not switch apps to chase accuracy. Switching resets your baseline and costs you the comparison, which is worth more than the accuracy you think you gained.
5. Judge by the trend over weeks, not by any day's total.

The short version

• Calories are calculated, not measured, and there is more than one legitimate multiplier.
• USDA publishes two energy figures for the same food; an app has to choose one.
• Carbohydrate is obtained by subtraction, so other measurement errors land inside it.
• A US label is a rounded band, and for calories the tolerance is one-sided.
• A photographed estimate involves no lookup, so it is not comparable to one.
• Log the same way every day: a stable error drops out of the trend, a scattered one does not.

Please read. This is a method for counting, not dietary advice. If you are managing a medical condition, pregnant or breastfeeding, or working to a therapeutic diet, use the figures your clinician gives you. If counting is making your relationship with food worse rather than better, stopping is a reasonable answer — in the US the National Alliance for Eating Disorders helpline is 1-866-662-1235. See our health disclaimer.