Last reviewed: July 2026

Where nutrition data actually comes from

Every calorie figure you have ever seen traces back to one of three places: a manufacturer's own declaration on a package, a government laboratory dataset such as USDA FoodData Central, or a volunteer typing a label into a community database. Dietly runs on all three, plus its own community submissions and a small number of clearly labelled AI estimates. No one anywhere sends millions of products through a laboratory, and any service that implies otherwise is describing something that does not exist.

Stream one: the manufacturer's declaration

A packaged food's panel is written by its producer. Under EU rules the declared values may be derived from laboratory analysis of the product, from calculation using the known values of the ingredients, or from generally established and accepted data. All three are legal and all three are common, and calculation is the cheapest, so it is the most used. Official guidance then allows a tolerance of roughly 20 percent for many nutrients before a declared value is considered incorrect. That is not a scandal, it is what happens when a natural product varies from batch to batch, and it is covered in more depth in how accurate calorie labels are.

Stream two: laboratory datasets

Generic foods, the raw chicken breast and boiled potato entries that underpin almost every recipe calculation, come from national food composition tables. The largest and most reused is USDA FoodData Central, which is United States public domain data. Its Foundation Foods and SR Legacy datasets are genuine laboratory analyses with sample counts and, in the newer sets, published variability. Its Branded Foods dataset is something different: manufacturer label data submitted by companies, so it inherits every property of stream one. Knowing which of the two you are looking at matters, because only one of them was ever in a laboratory. Dietly carries both, alongside the label data described below, and marks the source on every row.

Stream three: community transcription

Barcode coverage is the hard problem. No laboratory dataset contains the private-label yogurt sold in one Dutch supermarket chain, and manufacturers do not publish machine-readable panels for their entire catalogues. Open Food Facts solved this the only way it can be solved, with volunteers photographing and typing in labels, released under the Open Database License. The strength is coverage across countries no lab dataset comes close to. The weaknesses are typos, unit confusion and reformulation lag, because a product changes recipe and the database keeps the old numbers until somebody rescans it.

What Dietly does with the three streams

• Normalise everything to per 100 g. Incoming rows arrive per serving, per ounce, per package and in kilojoules. One unit makes comparison and search ranking possible.
• Deduplicate branded products by barcode, keeping the most recent record, so the same GTIN does not appear five times with five recipes.
• Run plausibility checks before a row is served, described below.
• Keep the provenance. Every row carries a source, one of Open Food Facts, USDA or an AI estimate, plus a confidence score, and both are returned by the API. If you cannot tell where a number came from, you cannot judge it.
• Refresh on a schedule, so upstream corrections and new products arrive without a manual import.

None of that is glamorous and none of it creates new nutrition knowledge. It makes existing public data fast to query, which is the whole product.

What still goes wrong, and how to catch it

Errors survive every pipeline, so it is worth being able to spot one. Four checks catch most of them, and you can run all four on any database, including this one:

• The 4, 4, 9 check. Protein and carbohydrate carry about 4 kcal per gram and fat about 9. An entry claiming 59 kcal per 100 g with 17 g of protein cannot be right, because the protein alone accounts for roughly 68 kcal. That pattern almost always means per-serving values were entered in the per 100 g field.
• The ceiling. Nothing edible exceeds about 900 kcal per 100 g, which is pure fat. A higher figure is a unit error.
• The 100 g rule. Protein plus fat plus carbohydrate cannot exceed 100 g per 100 g of food.
• The salt sanity check. Sodium above roughly 5,000 mg per 100 g means the row is describing a seasoning or, far more often, that grams were typed into a milligram field.

Sane entries pass all four quietly. Cooked shrimp at 59 kcal with 12.9 g of protein, lean ground beef at 152 kcal with 20.5 g of protein and 7.1 g of fat, and sardines in spring water at 190 kcal with 21.4 g of protein and 11.9 g of fat all reconcile against the 4, 4, 9 rule within label rounding. If you find one that does not, tell us and it gets corrected upstream as well as here.

Bottom line

Nutrition data is declared, analysed or transcribed, never conjured. Dietly layers Open Food Facts label data licensed under ODbL, USDA FoodData Central public domain data, its own community submissions and clearly labelled AI estimates, normalises them to per 100 g and shows you which is which. The seams are visible on purpose, because a number whose origin you cannot check is a number you cannot trust.