Where calorie counts actually come from.

Search “banana” in three calorie apps and you get three different numbers. None of them is lying, exactly. Here is what sits underneath the figure, and which part of it you should actually distrust.

There is a public database, and most apps start there

In the United States the reference is FoodData Central, published by the US Department of Agriculture. It is not one database but several stitched together, and the difference between them matters more than it sounds:

Most of the disagreement between two apps is not a disagreement about nutrition science. It is one app quoting a survey food, another quoting a raw ingredient, and a third quoting a specific brand — three different questions, answered correctly, presented identically.

The number was probably calculated, not measured

It is natural to picture a laboratory burning a slice of pizza in a calorimeter and reading off the heat. That is not, in general, how the figures in these databases are produced. Energy values are usually calculated from the macronutrients — how much protein, fat, carbohydrate and alcohol a food contains, each multiplied by a conventional energy factor and added up.

Those factors are averages, developed a very long time ago, and they are approximations by design. They do not account for how much of a particular food your particular digestion actually extracts, which varies with cooking, with processing, with the structure of the food, and between people. Whole almonds are the well-known example: chew them and a meaningful fraction of the fat simply passes through.

Figures are published per 100 grams. You did not eat 100 grams

Everything in FoodData Central is stored per 100 g, because that is the only form in which a nutrient figure means anything on its own. What you ate was a portion — a slice, a cup, a wing — and converting between the two is where the whole problem lives.

USDA does publish portion weights alongside the foods, and they are measurements rather than guesses. For a single food there are usually several:

1 piece, medium pizza · 274 kcal
1 piece, large pizza  · 406 kcal
1 personal size pizza · 658 kcal
100 g                 · 274 kcal

A factor of two and a half between the first and the third, for a food most people would describe with the same word. The lab figure is stable; the thing you are actually uncertain about is which row you ate. This is why arguing about whether a database says 274 or 280 is a waste of attention, and why the portion picker is the most important control in a calorie app.

Where apps quietly make it worse

Three habits turn a defensible figure into an indefensible one.

1. Baking the portion into the name

A list with one number per food has to smuggle the portion into the label: a row called “pizza slice”, because “pizza” could not be priced. Now the ambiguity is inside a string nobody can edit. The honest shape is a food, a portion, and a count — where multiplying a published portion weight by the number you say is arithmetic on your own answer, not a new guess.

2. Taking whichever portion happens to be listed first

Databases order portions by their own internal conventions, not by plausibility. Take the first one blindly and you get defaults like one almond, or a single stick of celery. Nobody eats one almond, so the default silently under-counts every time somebody accepts it — which is nearly always, because a default is a recommendation whether or not you meant it as one.

3. Shipping the whole database

FNDDS holds several thousand foods. Import all of them and searching “chicken” returns a wall of rows reading “Chicken, broilers or fryers, breast, meat only, cooked, roasted” and forty near-identical siblings. Completeness feels like rigour and reads as noise; the user picks whichever row is nearest the top, which is a worse answer than a short curated list would have given them.

What we do about it

Burnline ships 501 foods. Every one is generated from FNDDS rather than typed by hand, and each row keeps the FoodData Central identifier it came from, so any figure in the app can be walked back to the published record behind it.

A few consequences of taking that seriously:

• Portions are on the row, and editable. The form reads portion, then how many, then calories — because the quantity is the part only you know.
• A revised source is an error, not a silent update. The curation file pins both the identifier and the description it was curated against. If USDA changes a row, the import fails loudly rather than quietly moving a number under a name somebody already trusted.
• Foods that cannot be honestly portioned do not ship. Several were dropped for exactly this — a calzone offered as a whole 424 g one or nothing, pine nuts offered as a single nut or a whole cup. A row that cannot say what it is priced for cannot be trusted.
• The list is deliberately short. A test fails the build if any common word returns more than twelve rows. Curation is a feature, not a shortfall.

What to do with all this

Not despair, and not abandon tracking — the figures are useful, and consistency across days is worth more than precision on any one of them. But calibrate what you are trusting:

• Trust the relative comparisons. That a burrito is several times a banana is solid.
• Distrust the last digit. A day’s total quoted to the single calorie is precision theatre.
• Spend your attention on portions. That is where the factor-of-two errors are, and it is the one part you can actually get right.
• Prefer an app that tells you where a number came from. “You typed this”, “this is from the list” and “something estimated this” are three very different claims, and any app that renders them identically is hiding the only information you needed to judge its output.