Why two apps give the same roti different calories

Search "roti" in three calorie apps and you will get three different answers, possibly 71, 104 and 297 kcal. All three apps are working correctly. The disagreement is not a bug, and understanding where it comes from tells you which number to use.

An app is mostly a database with a search box

The interface is what you notice. The database is what determines the number, and most apps did not build theirs.

There are three kinds of source, in descending order of trust.

National food composition tables. USDA FoodData Central, India's IFCT, and their equivalents elsewhere. Built from laboratory analysis with documented sampling. This is the closest thing to ground truth that exists.

Manufacturer data. Label values for packaged products, reliable within the label tolerance of roughly 20 per cent.

User submissions. Typed in by members of the public, unverified, and by volume the overwhelming majority of entries in the largest apps.

An app whose first result is a user submission and an app whose first result is a composition table will disagree, and only one of them is telling you something checkable.

Reason one: user entries are guesses with a database around them

This is the single biggest source of variation.

When someone logs their mother's dal and creates a new entry for it, that entry becomes searchable by everyone. It reflects one kitchen, one recipe and one person's estimate of how much oil went in. Multiply by millions of users and you get dozens of entries for every common dish, spanning whatever range of recipes and guesses exist in the population.

There is also a bias. People creating entries for their own food tend to enter flattering numbers, and those entries then get logged by thousands of others.

Reason two: raw versus cooked

Rice roughly triples in weight when boiled. Meat loses a quarter when roasted. An entry for "rice" might mean either state, and many do not say.

That single ambiguity explains gaps of 200 per cent or more between entries that are both technically correct about different things. The full picture is in should you weigh food raw or cooked.

Reason three: serving definitions

"One roti" is not a quantity. Rotis range from 30 g to 60 g, which is a factor of two before anyone argues about flour or ghee.

"One serving" is worse: it defines nothing at all, and yet it appears on an enormous number of database entries. Entries that give a weight are usable; entries that give a name are not.

This is the same problem covered in serving size and it is the reason calibrating your own portions matters more than finding a better app — see how to track calories without a food scale.

Reason four: different countries, genuinely different food

A roti in an American database is a wheat flatbread analysed in the United States. A roti in IFCT is made from Indian atta, which differs in extraction rate, fibre and moisture.

Neither is wrong. They are different foods with the same name, which is exactly why a table built for one food supply produces confidently incorrect numbers for another. This is the subject of IFCT or USDA: which numbers should you trust.

Reason five: fibre and carbohydrate conventions

Some labelling systems declare total carbohydrate including fibre; others declare available carbohydrate with fibre listed separately. Fibre is also assigned a lower energy value than other carbohydrate, and different systems assign different values.

For a high-fibre food this produces a real difference in the computed calorie total between two sources that are both following their own rules correctly.

Reason six: carbohydrate calculated by difference

Many composition values do not measure carbohydrate directly. They measure water, protein, fat and ash, and subtract from 100. Everything left is called carbohydrate.

That means every small analytical error in the other four components accumulates in the carbohydrate figure, and therefore in the calorie total. It is a sound method and it carries inherent noise.

Which number should you use?

Three rules, in order.

Prefer a named source. An entry citing a composition table or a manufacturer beats one citing nothing.

Prefer a stated weight. Grams per 100 g, not "1 serving".

Then stop optimising and be consistent. Pick the entry, save it, reuse it forever.

That last rule is the one people skip and it matters most. A log using the same slightly-wrong entry every day still produces a usable trend, because the error is constant and your weekly weight change corrects for it. A log that picks a different entry each time has variable error, which destroys the signal — the argument in how accurate are calorie counts, really.

What a good app does about this

It shows you the source of every number, distinguishes verified entries from user ones, states the state and the weight, and does not return forty results for a common dish.

That is a database design decision rather than a feature, which is why how to judge a calorie app's food database is a more useful question than which app has the nicest charts.