Why crowdsourced calorie databases are broken

Crowdsourced database: a food database where entries are typed in by the app's own users — anyone can add a food, and nobody checks the numbers before they go live.

Curated database: a food database built and maintained by a single accountable publisher — for USDA FoodData Central, that publisher is the U.S. Department of Agriculture, and the core records come from laboratory analysis.

Most of the big calorie apps run on the first kind. This article is about what that costs you.

The problem, in one search

Open a crowdsourced tracker and search for "banana". You won't get one result — you'll typically get hundreds: "Banana", "banana raw", "Banana - medium", "BANANA!!", "banana (1)", each with its own calorie figure, some per piece, some per 100 g, some per "serving" of unstated size. Reported values for the same medium banana commonly range from about 70 to over 130 kcal.

The USDA answer is singular: raw banana is 89 kcal per 100 g — 1.1 g protein, 0.3 g fat, 22.8 g carbohydrate. A medium fruit (118 g peeled) is about 105 kcal. One record, one provenance, and you can look it up yourself at fdc.nal.usda.gov.

Where crowdsourced numbers go wrong

• No verification. Entries go live the moment a user saves them. A typo — 210 kcal instead of 120 — looks exactly as authoritative as a correct entry.
• Serving-size confusion. "1 serving" of rice can mean 45 g dry, 100 g cooked, or a full 250 g plate depending on who typed it. The calorie field can be right while the entry is still useless.
• Cooked vs raw mixups. Rice roughly triples in weight when boiled: dry white rice is about 365 kcal per 100 g, cooked is about 130 kcal per 100 g (USDA). A user entry that doesn't say which state it means can be off by a factor of ~2.8.
• Label transcription drift. Users copy old labels, foreign labels, or labels for a different variant (light vs regular) onto the same food name.
• Duplicates never die. Even when a good entry exists, nothing steers the next user toward it — so the pile of variants keeps growing and voting-style cleanup never catches up.

The practical result: two people logging the identical meal in the same app can end the day hundreds of calories apart, and neither can tell who is right, because neither number has a source.

Why the errors matter more than they look

A calorie deficit for steady weight loss is typically 300–500 kcal per day. Database noise of 10–20% on a 2,200 kcal day is 220–440 kcal — the same order of magnitude as the entire deficit. You can be perfectly disciplined about logging and still see no progress, not because tracking "doesn't work", but because the numbers being summed were never right.

What a curated database does differently

USDA FoodData Central is in the public domain, covers thousands of foods across its SR Legacy and FNDDS datasets, and states energy explicitly as nutrient 1008 (kcal). When a number comes from there, "where did this figure come from?" has an answer.

How Calorie.one uses this

Calorie.one doesn't let a model — or a crowd — invent nutrition numbers. AI does one job: reading your description or photo and splitting the meal into ingredients with gram amounts. Each ingredient is then matched against USDA FoodData Central, and every line in your log carries a source label: usda (matched directly to a USDA record), mixed (partly estimated), or ai (no acceptable match; clearly labeled as an estimate). You can unfold any meal and check the lines behind the total — which is exactly what a crowdsourced entry can never offer.

And yes, you can now add a food yourself

That deserves saying plainly, because it sounds like the thing this article just spent a thousand words criticising.

USDA does not have your local bakery's rye bread, and it never will. A tracker that refuses to let you log it is not more accurate — it just pushes you to guess, or to pick a USDA row that is nearly-but-not the thing you ate. So Calorie.one does let people add foods. The five failure modes above are the specification it had to satisfy first.

No verification → checked before it goes live. An entry's calorie figure is cross-checked against its own macros. If the numbers disagree with 4·protein + 4·carbs + 9·fat by more than the tolerance real food actually shows, it is refused with an explanation. The tolerance isn't a guess: it was fitted against all 7,694 USDA rows the app ships with. It is also asymmetric, because the two directions mean different things — declaring *fewer* calories than the macros imply is the dangerous one and gets a wide but bounded allowance for fibre and sugar alcohols, while declaring *more* has exactly one honest explanation. Of those 7,694 USDA rows, 64 exceed their macro estimate, and every single one is an alcoholic beverage. So a surplus is only accepted if you say the food contains alcohol, and only up to what a neat spirit can account for.

Serving-size confusion → a gram weight is mandatory. You cannot save a food without at least one named serving and what it weighs. "1 slice" with no grams is exactly the entry that makes people guess, and the guess is the error.

Cooked vs raw → a required field, never defaulted. Every contributed food has to state whether its numbers are for the food raw, dry or cooked. Dry pasta at 371 kcal and cooked pasta at 157 is the most expensive confusion in calorie tracking, and a default would bake it in.

Label transcription drift → anyone can report it, and a person reads it. One report per person per food, so the count measures how many people agree rather than how insistent one person is. The moderation queue existed before the report button did; a report button nobody answers is worse than none, because it implies a review that never happened.

Duplicates never die → a duplicate is refused at the door. A name that already exists — in USDA or in the community entries — comes back with a link to the food it would have duplicated. One that slips through gets merged into the original rather than deleted, because meals that already used it were priced from it.

Two more things do the real work. A contributed food is ranked, not trusted: it is findable from the first minute and sits below the USDA rows until other people have actually used it. What counts is how many *different* people logged it, never how many times — so nobody can promote their own entry by logging it fifty times, which is precisely how crowdsourced databases get gamed.

And it never wears the USDA badge. A community entry says COMMUNITY, everywhere, permanently, alongside how many people have used it. The AI is not allowed to look one up either: automatic ingredient matching still only ever reads the curated USDA rows, so a wrong user entry cannot end up quietly grounding a stranger's photo.

That is the whole bargain. A bigger database than USDA alone, and never any doubt about which half of it you are looking at.

FAQ

Are crowdsourced calorie counts always wrong?

No — many individual entries are accurate. The problem is you can't tell which ones, because entries carry no source and conflicting duplicates sit side by side. A database is only useful if you can trust a result you didn't personally verify.

Is the USDA database accurate for branded products?

USDA's branded food section relies on manufacturer-supplied labels, which are more variable than the lab-analyzed SR Legacy data. For whole foods and generic dishes — chicken breast, rice, eggs, a banana — the lab-analyzed records are the gold standard. Calorie.one grounds its numbers in the SR Legacy and FNDDS datasets.

Why do two calorie apps show different numbers for the same food?

Usually because they query different databases — or different user entries within the same crowdsourced database. Two apps grounded in the same USDA record would agree, since the record states one value per 100 g.

If Calorie.one accepts user-added foods, isn't it crowdsourced too?

Partly, and it says so on every entry. The difference is not whether users can contribute — it is whether a contribution is checked, whether it can impersonate a verified record, and whether the app tells you which is which. Contributed entries are validated against their own macros before they go live, must declare raw/dry/cooked and a serving weight, rank below the USDA rows until other people use them, and carry a COMMUNITY label that they can never lose. The failure of a crowdsourced database is not user entries; it is user entries that look identical to verified ones.

Can I check a USDA number myself?

Yes. USDA FoodData Central is free and public at fdc.nal.usda.gov. Search the food, open the record, and read the energy value (nutrient 1008) directly.