Raw or Cooked? What Your Food Scale Is Actually Telling You

You buy a pound of chicken breast, roast it, and put 6 oz on the plate. Do you log 6 oz, or do you log the raw weight it came from? The two numbers are not the same, and they are not the same by a lot.

Most answers to this question stop at "be consistent," which is true but not very useful when you are standing over a hot tray trying to decide what to type into an app. Here is what is actually happening to the food, and what to do about it.

What cooking actually changes

The USDA measures this directly. Their Table of Cooking Yields for Meat and Poultry defines cooking yield as the hot cooked weight divided by the raw weight, times 100. Their broiler-fryer chicken breast, baked or roasted, comes in at about 72%. Poach the same cut instead and it lands nearer 77%. Your own breast will not hit those numbers exactly, since trim, thickness and how long you leave it in all move the figure, but the neighborhood is right.

So a 6 oz cooked breast started life somewhere around 8 oz raw. If you logged 6 oz against a raw database entry, you just under-counted roughly a quarter of your chicken.

The important part is what moved. The USDA table tracks two things that change during cooking: moisture and fat. Protein and carbs do not evaporate. A raw chicken breast and the cooked breast it turns into contain nearly the same grams of protein. The protein is just packed into less water, which is why cooked chicken reads higher in protein per 100g than raw chicken does.

That reframes the whole question. Raw versus cooked is usually a units problem, not a calorie problem. You are describing the same food with two different rulers.

So which one is more accurate?

Neither, on its own. Accuracy comes from matching the weight to the database entry. Weigh raw, log the raw entry. Weigh cooked, log the cooked entry. USDA FoodData Central carries both versions of most foods for exactly this reason.

For ingredients you control, default to the state the package describes: raw meat, dry rice or pasta, uncooked oats. That is the state the label was written for, and it is before you added oil, sauce, or water. Fewer variables to get wrong. If you weigh it cooked, use a cooked entry. And if you are eating out of a batch someone else already cooked, the package state is not available to you, so reaching for it is a fake precision.

It is worth keeping the size of this error in perspective. When researchers compared what people reported eating against what they actually ate, measured by doubly labeled water, Lichtman and colleagues found intake under-reported by roughly half in a group of people convinced they were eating under 1,200 calories. Nobody misses by that much because of raw versus cooked chicken. They miss it on the things that never make it into the app at all: cooking oil, the handful off the tray, the second pour.

Raw versus cooked is a rounding error compared to the food you never logged. Fix the second one first.

The exception where it is not just units

The units framing holds as long as nothing but water moves. The main exception is when fat or added liquid actually leaves or enters the food: fatty meat you drain, bacon, oil you fried in, a braising liquid you tip down the sink. In those cases the calories really do change, not just the ruler. The clearest version is drained meat, and it is worth knowing the size of it.

In the same USDA data, lean ground beef under 12% fat, pan-broiled as a patty, yields 77% and loses only 1.4% of its starting weight as fat. Almost all of the loss is water. But ground beef above 22% fat, pan-broiled, yields 69% and loses 12.4% of its raw weight as fat. That fat is in the pan, not in your dinner. Bacon is the extreme version: microwaved, it yields 29% and sheds over 35% of its raw weight in fat.

So if you brown fatty ground beef and drain it, logging the raw weight overstates what you ate, and the gap is real fat calories, not water. Two options: log the drained cooked weight against a cooked entry, or buy leaner mince so the question stops mattering. With 93/7 the difference is small enough to ignore.

Logging a batch you cooked in bulk

This is where most people actually get stuck, and it has a clean solution.

1. Weigh every ingredient raw, as you add it, including the oil. Log the whole recipe as one entry.
2. When it comes out of the oven, weigh the entire finished dish, pan subtracted. Call that the yield.
3. Divide. If the tray totals 1,600g cooked and the recipe came to 2,400 kcal, that is 1.5 kcal per gram. Now any portion you serve is a multiplication.

This handles the sauce, the oil, and the water loss in one step, and it means you only do the math once per batch instead of once per meal. It is the same principle as building the week's numbers before the week starts, which is the approach laid out in the meal-prep math walkthrough.

Save the per-gram number in your notes app next to the recipe. If you cook the same recipe the same way, you can reuse it as a working estimate. Reweigh the finished dish when the batch size or the cooking method changes, because the yield moves with both.

When all you have is the cooked weight

Someone else cooked it, or you forgot to weigh before it went in. You can work backward, roughly.

Across the 173 entries in the USDA yield table, the median cooking yield is 76%, and about four in five entries land between 65% and 85%. So dividing a cooked weight by 0.75 gets you a serviceable estimate of the raw weight for most meat and poultry. A 150g cooked chicken breast becomes roughly 200g raw.

Treat that as a bridge, not a method. It is wrong for bacon, wrong for anything braised in liquid, and useless for rice and pasta, which run the other direction and gain weight as they absorb water. Rice roughly triples. If your database entry says "cooked," use it and stop converting.

For food you did not cook and cannot weigh at all, the estimation problem is different and worse. That is covered in tracking restaurant meals, where the honest answer is to anchor on the protein and accept a wider band on everything else.

The rule that actually matters

Pick one convention per food and hold it. Chicken always raw. Rice always dry, or always cooked, but never whichever you happen to reach for. Ground beef always drained-and-cooked. Write it down if you have to.

The reason is not precision, it is drift. If you weigh raw on Sunday and cooked on Wednesday, your logged intake moves around by 20 to 30% on the same actual food, and you lose the ability to read your own data. A consistent log is what lets you look at four weeks of numbers and conclude something. In the systematic review by Burke and colleagues, people who self-monitored more consistently lost more weight than those who did it sporadically. Consistency was the variable that moved, not decimal places.

Building that consistency into the kitchen rather than into willpower is the whole point of a prep system that holds up midweek. If the containers are already portioned and the per-gram number is written on the lid, there is no decision left to get wrong.

The short version

• Cooking moves water and fat. It does not move protein or carbs.
• Match the weight to the database entry. Raw with raw, cooked with cooked.
• For ingredients you control, default to the package state: raw meat, dry rice or pasta, uncooked oats. Weigh it cooked, use a cooked entry.
• The difference stops being cosmetic when fat or liquid leaves or enters the food: drained fatty meat, bacon, absorbed frying oil, a discarded braising liquid. Log drained foods cooked, and log added oil separately when you control it.
• For batches, weigh the ingredients raw and the finished dish whole, then work in calories per gram.
• One convention per food, every time.

If you are not sure what those daily numbers should be yet, the macro calculator gives you a starting point to weigh against. Get the targets roughly right, then get the logging consistent. In that order.