Understanding Per-100g vs. Per-Serving Nutrition Data

USDA reference databases, including every food and ingredient page on this site, report nutrient values per 100 grams of food — a fixed scientific unit that makes any two foods directly comparable. A Nutrition Facts label instead reports nutrients per labeled serving, a size the manufacturer sets based on typical consumption. The two numbers describe different amounts of the same food.

---

Why does USDA measure nutrients per 100 grams instead of per serving?

A 100-gram basis is a laboratory and database convention, not a consumer-facing one, and that's precisely its advantage: it removes serving size as a variable entirely, so every food and ingredient in a database can be compared on exactly equal footing. This site states that convention directly on every ingredient page, in its own sourcing note: values "come from the USDA FNDDS survey nutrient database... They are per 100g of the ingredient as described, not per serving." That's not a stylistic choice unique to this site — it reflects how the underlying USDA FoodData Central dataset itself is structured, and it's why the raw number on an ingredient or food page here will essentially never match the number printed on a grocery-store label for the "same" food, even when both are measuring the same real-world ingredient.

What's the actual difference between a "serving" and "100 grams"?

The two units answer different questions. Per the FDA's own explainer on serving size, "serving sizes must be based on the amount of food people typically consume, rather than how much they should consume," and critically, "the serving size is not a recommendation of how much to eat or drink" — it's a consumption-pattern estimate set per food category, which is why a serving of ice cream and a serving of leafy greens are wildly different gram amounts. A 100-gram basis asks none of that; it's a fixed, arbitrary unit of mass that applies identically to every food regardless of how anyone eats it. Comparing two foods' label servings tells you about typical consumption habits for each; comparing two foods' 100g values tells you about their composition, independent of portioning.

Does this database ever show a per-serving number instead of per-100g?

For a subset of foods, there's a related but distinct figure available: a gram-weight equivalent for a common measure, like "1 slice" or "1 container." This database's food_portion table records exactly that — for whole-wheat bread, for example, it records that one slice weighs 32.1 grams; for plain nonfat Greek yogurt, it records that one container weighs 156 grams. But that's a weight conversion, not a recalculated nutrient value — the energy, sodium, and carbohydrate figures stored against each food stay expressed per 100g regardless; nothing in this database pre-computes and stores a "per slice" or "per container" nutrient amount anywhere. Getting an actual per-portion number means taking the per-100g figure and scaling it yourself using that gram weight — which is exactly what this guide walks through next.

A worked example: converting a real per-100g value into an actual portion

Take the Greek yogurt example above. This database's own queried data puts it at 61 kcal, 10.3g protein, 0.37g fat, 3.64g carbohydrate, 36mg sodium, and 111mg calcium per 100 grams. The same food's recorded "1 container" portion weighs 156 grams, so the scaling factor is 1.56 (156 ÷ 100). Multiplying every per-100g figure by that factor gives the actual container's content: roughly 95 kcal, 16.1g protein, 0.58g fat, 5.68g carbohydrate, 56mg sodium, and 173mg calcium. None of those per-container numbers exist anywhere in this database as stored values — they're a hand calculation from two real, independently queried database fields (the per-100g nutrient amount and the recorded portion gram weight), not an estimate or a number pulled from an external label. The same method works for any food in this database that has at least one recorded portion: take the per-100g value, multiply by (portion gram weight ÷ 100).

Why can't every item on this site be converted to a per-serving number this way?

Because the portion-weight data the conversion depends on simply doesn't exist for most of this database's content. The food_portion table that supplies gram-weight equivalents is keyed only to food.fdc_id — the smaller, more tightly curated set of Foundation and SR Legacy foods — and even within that set, coverage is partial: a direct query returns 447 portion rows covering 318 distinct foods out of the 469 total foods in this database, or about 68%. The much larger FNDDS ingredient set — 1,882 ingredients, the bulk of this site's nutrient content — has no portion-weight data at all, for a structural reason, not a missing-data oversight: ingredient_meta and the fndds_ingredient_nutrient_value table it's built on have no gram-weight or portion-description column anywhere in their schema. There's no field in this database that could even hold a serving size for an FNDDS ingredient like avocado, whether or not USDA's own source survey happened to record one. This site's own codebase documents this gap explicitly, in a developer comment on the ingredient page template noting a planned "per-serving toggle" is still open specifically because it "needs common portion sizes, which FNDDS ingredients do not carry."

What does that gap mean in practice when you're using this site?

It means the conversion shown above is only available for a minority of records here, and only for foods, never for FNDDS ingredients. If you're looking at one of the 318 foods with recorded portion data, you can scale its per-100g values into a real-world amount yourself using the method above. If you're looking at any of this site's 1,882 ingredient pages, or one of the 151 foods without a recorded portion, the per-100g figure is the only number available, and there's currently no gram-weight equivalent on this site to scale it by — you'd need to weigh the actual food yourself, or find a portion reference from another source, to convert it.

Does a package's own label ever show more than one serving-based number?

Sometimes, and it's a useful point of contrast with how this site's per-100g figures work. The FDA's serving-size guidance notes plainly that "one package of food may contain more than one serving," and some packaged foods are required to carry a second column of figures covering the entire container alongside the standard single-serving column, so a shopper can see both at a glance. Either way, both of those columns are still per-serving-style numbers, scaled to "amount typically consumed" in one sitting or across the whole package — not a per-100g figure. A product like that, if it also had a corresponding entry in this database, would effectively have three different ways to express its sodium content: per 100g (this site's figure), per labeled serving, and per package — and none of the three is wrong; they're just answering three different questions about the same food.

How should you use per-100g data if you want to know what's actually in your bowl?

Treat the 100g figure as the composition baseline, not the finish line. It's the right number for comparing two foods' nutrient density, for checking a specific nutrient's concentration, or for scaling precisely once you know (by a kitchen scale or a recorded portion weight) how much you're actually eating. It's the wrong number to read as if it were a single-sitting amount — 100 grams of chia seeds and 100 grams of leafy greens are both "100 grams," but almost nobody eats either of them in that exact quantity at one sitting. When a recorded portion weight is available on this site, use it the way the worked example above does; when it isn't, the most reliable path to a real per-serving figure is weighing your own portion and doing the same multiplication by hand.

---