Crowd-Sourced Food Database Errors

The food is usually right; the amount attached to it is not#

Ask people what goes wrong in a crowd-sourced food database and they describe a wrong food: someone typed in a burger and got a salad's numbers. That is not what the measurements show. When a trained researcher took thirty 24-hour dietary recalls collected with research-grade software and entered the same foods into five popular apps — MyFitnessPal, Fitbit, Lose It!, MyPlate and Lifesum — between 78% and 83% of entries were classified as close matches, and outright poor matches ran at 0–1%. The mismatches that did occur split sharply: 13–17% were poorly matched on amount, against only 4–6% on description¹.

Read that ratio again, because it reframes the whole problem. A professional, working carefully with known foods, found the right food about 96% of the time and the right quantity about five times in six. The database knows what a chicken thigh is. What it does not reliably know is how much food the entry in front of you is describing — and quantity is the input the calorie figure is most sensitive to. The full error stack around this is the pillar's subject (how accurate calorie counting is); what follows is the layer inside the database itself.

A blank field and a zero look identical downstream#

The second structural defect is about what a crowd-sourced entry is allowed to omit. In four of the five apps tested, members can upload their own food entries with nutrient information that then becomes available to every other user. And when they do, as the researchers note, they "are not required to enter each nutrient that the app reports on. Thus, there may be missing values for some nutrients"¹.

A missing value and a zero are different claims about the world. One says "this food contains none of that." The other says "nobody typed it in." Downstream, in a daily total, they are the same number — and because a blank can only ever pull a total down, the error has a direction rather than a scatter. Every one of the five apps significantly underestimated at least one nutrient against the research reference, by 7% to 41%. Which nutrients each app missed, and what that means for reading a daily panel, is tabulated in how accurate calorie-tracking apps are.

The contrast with a curated reference is not subtle. USDA's FoodData Central publishes Foundation Foods as "data and metadata on individual samples ... with insights into variability," while its Branded Foods records are explicitly "based on food label information" supplied by manufacturers⁴. Both tell you what kind of number you are holding. A user-submitted entry carries no equivalent: no analyst, no method, no sample count, no date. Not a wrong provenance — no provenance field at all. The architecture of that reference system, and why it forks, is taken apart in why calorie estimates vary.

What a "verified" badge actually certifies#

Most consumer apps mark some entries as verified, and most users read that mark as "this entry is correct." It is a narrower claim than that. Describing MyFitnessPal's verification system, the same researchers record that the icon indicates the completeness of energy and macronutrient information, and that such entries "may be subject to nutrient inaccuracies"¹.

The badge is a completeness check on four fields, not a correctness check on the entry. It certifies that somebody filled in the boxes.

That is still worth something — a complete entry beats a hollow one, and the four fields it covers are the four that matter most for calorie tracking. But it explains a pattern users find baffling: verified entries that disagree with each other. Two entries can both be complete, both be badged, and both be describing different amounts of the same food.

Barcoded packaged goods are the strongest case in a crowd-sourced database, because the scan bypasses the search entirely and the underlying figure is a manufacturer's declaration rather than a stranger's typing. That declaration has its own well-defined slack — it is computed by one of several permitted methods and printed on a coarse rounding grid under 21 CFR 101.9 — but it is at least slack you can characterize. That is the whole argument for scanning where a scan exists, examined further in how accurate barcode scanning is.

The database inherits whoever populated it#

The most underrated property of a crowd-built database is that its coverage is a demographic artifact. Foods that many users log get many entries, refined by repetition. Foods that few users log get thin, stale, or absent ones — and the resulting error is not random noise, it is a systematic function of what you eat.

That shows up cleanly in a 2024 evaluation from Australia. Researchers screened 800 nutrition apps, assessed 18 in depth, and compared the nutritional output of 16 manual food-logging apps against three-day food records for three standardized diets. For the Western diet, 14 of the 16 apps overestimated energy, by a mean of 1,040 kJ. For the Asian diet, 13 of the 16 underestimated it, by a mean of 1,520 kJ². Converting those to calories — my arithmetic, not the paper's — that is roughly +249 kcal and −363 kcal.

Same apps, same day, opposite signs. This is not two studies disagreeing; it is one study finding that the error flips direction with the cuisine. Nobody using an app built largely on one food culture is going to see a warning when they log a dish from another; the entry appears, the number looks plausible, and the shortfall is invisible. For anyone eating outside the database's center of mass, that is the single most consequential finding on this page.

Every published accuracy figure is a best case#

Two caveats belong on all of the above, and the first comes from the authors themselves. The Griffiths study "did not evaluate the level of accuracy that may result if an individual entered her/his own foods and food amounts. Rather, a trained professional searched for and entered foods"¹. Every figure in this article is therefore a ceiling. A dietitian selecting entries deliberately mismatched the amount in up to one entry in six; a tired user scrolling a results page at 9pm is not doing better than that.

The second caveat is about the numbers this topic usually gets argued with. Single, striking percentages — a specific share of entries said to be wrong by a specific amount — circulate widely on pages selling competing trackers, and we could not obtain a primary study behind them. A statistic whose only traceable home is marketing is not evidence, however often it is repeated, and it is not used here. What has actually been measured is less dramatic and more useful: matching fails on quantity far more than on identity, blanks propagate as zeros, and coverage tracks the user base.

Working with a database that cannot flag its own gaps#

Four habits do most of the available work.

Check the gram weight, not the food name. Given that mismatch concentrates on amount, the entry's underlying quantity is the field worth two seconds of attention. An entry reading "chicken thigh — 1 thigh" is making a claim about mass that you can accept or override; "chicken thigh — 130 g" is one you can verify.

Prefer a scan, then a branded entry, then a generic one. In that order, provenance goes from a manufacturer's declaration, to a manufacturer's declaration retyped, to a stranger's estimate of an abstraction.

Treat a zero as unknown until proven. A crowd entry showing 0 mg sodium for a restaurant dish is almost always a blank field, not a sodium-free meal. For calories and macros this rarely bites; for anything else on the panel it routinely does.

Stay in one tool. All of the defects above are stable within an app. The same search returns the same entry tomorrow, so the offset is close to constant — and a constant offset cancels out of the comparison you actually run, which is this week against last. Switching apps mid-diet changes the ruler halfway through the measurement. Where a food's number comes from before any of this begins is covered in calories in common foods.

FAQ#

Are crowd-sourced food databases accurate enough to track calories with?#

For energy, generally yes. In head-to-head testing against a research-grade reference, energy and macronutrient correlations ran r = 0.73 to 0.96, while sodium, sugars, fiber and cholesterol were looser at r = 0.57 to 0.93¹. Calories are the figure these databases are built around and the figure they handle best; the rest of the nutrient panel is incidental.

Why are there so many versions of the same food in my app?#

Because in most consumer apps any member can upload an entry that then becomes available to all users¹, and nothing merges near-duplicates. The versions usually differ in assumed portion rather than in the food itself, which is exactly where matching was measured to fail most often — so compare the gram weights, not the names.

Does a verified check mark mean the entry is correct?#

Not on its own. The verification icon indicates that energy and macronutrient fields are complete, and verified entries "may be subject to nutrient inaccuracies"¹. It is a filled-in-boxes check, which is why two badged entries for one food can still disagree.

Sources#

This article was researched and drafted with AI assistance and reviewed for accuracy by the BurnWeek team. It is general information, not medical advice. How we research and correct our articles →