The answer, and why it is not the interesting part
Weigh food in the same state as the nutrition entry you are logging it against. Raw weight, raw entry. Cooked weight, cooked entry. That is the rule, and it is short because the underlying fact is short: cooking moves water, not calories.
What makes this question worth a page is that almost nobody gets it wrong the way they think they do. The mistake is not picking raw when you should have picked cooked. The mistake is an unmatched pair — weighing the chicken after it comes off the pan, then logging it against the entry that describes it before.
What the database actually says
USDA FoodData Central publishes the same food more than once, in different states, and every one of those rows is per 100 g. Here is one pair, both from the SR Legacy dataset, both the same cut of the same bird:
| Entry | FDC ID | Water | Energy | Protein |
|---|---|---|---|---|
| Chicken, broiler or fryers, breast, skinless, boneless, meat only, raw | 171077 | 73.9 g | 120 kcal | 22.5 g |
| Chicken, broiler or fryers, breast, skinless, boneless, meat only, cooked, grilled | 171534 | 66.1 g | 151 kcal | 30.5 g |
Values per 100 g, USDA FoodData Central, SR Legacy, retrieved 2026-08-12.
Read the water column first. It is the entire story. Between those two rows about eight grams of water per hundred left the meat, and everything that carries energy stayed. So 100 g of the grilled breast is simply more chicken than 100 g of the raw one, and the calorie figure follows: 151 against 120, a difference of about 26%.
Nothing here is a discrepancy between sources, or a rounding artefact, or a reason to distrust the database. Both numbers are correct. They answer different questions, and the question is set by which side of the pan you weighed on.
Foods that absorb water run the same mechanism backwards. Rice and pasta take on water rather than losing it, so their cooked rows are lower per 100 g than their dry ones — substantially lower, because a lot of water goes in. The rule does not change: dry weight against the dry entry, cooked weight against the cooked one.
So which should you actually use
Raw is more reliable for meat, and the reason is variance, not correctness. The USDA row above says “grilled”. Braised is a different row again, with different water content. Your pan, your heat, your timing and how long the breast sat afterwards all move the finished weight, and none of that moves the raw weight. Weighing before you cook takes the most variable step out of the measurement entirely.
Cooked is perfectly acceptable when the raw weight is not available to you. Food you bought already cooked, a portion served out of a shared dish, a batch someone else made — you cannot retroactively weigh those raw, and inventing a raw figure is worse than using the cooked row that exists. Rotisserie chicken is the honest example: use a cooked entry, and keep using it.
Consistency beats the choice. If you weigh a food cooked every time and log it against a cooked entry every time, a residual error stays constant, and a constant error is nearly harmless for the thing most people are actually doing — comparing this week to last week. Alternating between conventions on the same food introduces a swing of roughly a quarter, in a direction that changes without warning, and it is undetectable afterwards. Daily totals never look wrong. That is what makes this specific mistake expensive: it does not announce itself.
What this looks like in a real catalog
Here is the part I care about, because it is where the general advice stops being useful and the workflow starts.
When I was building the product’s food catalog, this question stopped being “which is more accurate” and became a data-modelling problem: where does the raw-or-cooked decision live? Three options, and only one survives.
It cannot live in your head — you would have to remember, per food, which convention you picked, months later, while cooking. It cannot live in the log entry either, because then every single meal re-asks a question you already answered. So it has to live in the product entry — the thing you create once and reuse forever.
That is why Pantensa builds around a catalog you set up once. A product carries the nutrition values you confirmed and the state they describe, and every recipe and every planned meal that references it inherits both. You make the raw-or- cooked decision at the moment you have the database entry open in front of you, which is the one moment you can actually see what it says. After that the decision is made, and it stays made. If you want the mechanics of that in more detail, how the catalog works walks through it.
The practical corollary is a naming habit that costs nothing: put the state in the product name. “Chicken breast, raw” and “Chicken breast, grilled” as two separate catalog entries, not one entry you mentally adjust. They genuinely are two different products from a measurement point of view, and naming them apart means the choice is visible at the moment you log, rather than recalled.
Where the database does not cooperate
I would rather say this plainly than let the section above imply more than it should.
Not every food has a matched pair. The chicken example is clean because USDA happens to publish raw and cooked rows for that exact cut. Plenty of foods have only one state in the database, and it is not always the one you have in your kitchen. When only a cooked row exists and you have the food raw, you either weigh it cooked or you accept an approximation — there is no third option that is secretly more accurate.
Branded entries usually will not tell you. Barcode scanning lands in Open Food Facts, which is built from packages, and a package states what is inside it as sold. For anything you cook, that is a raw-state figure whether or not the entry says so. This is one of several reasons imported values arrive as something to review rather than accept — the state a number describes is exactly the kind of thing you can only check while you are holding the package.
Yield varies more than a single row can express. USDA’s grilled and braised rows for the same chicken breast differ from each other, and neither is your pan. Treat a cooked row as a good central estimate, not as a measurement of the thing on your plate.
None of that makes the numbers useless. It makes them numbers with a stated provenance, which is a genuinely useful thing to track, and it is why I would rather explain the limits here than imply precision the data does not have.
The whole thing, in two lines
Match the weight to the row. Then pick one convention per food and keep it — the consistency is worth more than the choice, and it is the part that survives you forgetting about this article.