How to calculate macros for a recipe, and the four things that make it wrong

By Dave Campbell · 18 October 2026 · 6 min read

Every guide to this says the same thing, and the arithmetic is genuinely simple. Price each ingredient, add it up, divide by the servings.

I built that. Then I measured it against 220 recipes whose authors publish their own nutrition panels, and it was out by 39% on calories. Fixing the arithmetic was not what closed the gap. Four other things were, and only one of them is mentioned by the pages currently ranking for this question.

Here is the method, and then what breaks it.

The method

1. Write down every ingredient with a weight. Grams, not cups. A cup of diced onion and a cup of finely chopped onion are different weights, and no table can tell them apart.
2. Look up each one per 100 g and scale it to what you used.
3. Add the four numbers across every line: calories, protein, carbs, fat.
4. Divide by the number of servings the recipe actually makes.
5. Sanity check with Atwater. Protein and carbs are about 4 calories a gram, fat about 9. If your protein, carbs and fat do not roughly reconstruct your calorie figure, one of the four is wrong.

That is the whole thing. Now the parts that decide whether the answer is any good.

1. A recipe weighs food raw, a food diary means it cooked

This is the big one, and it is the thing the current top results get backwards. One of them says, plainly, that cooking changes weight but not macros, so you should weigh raw for consistency.

Half right. Cooking does not change the protein and carbohydrate much. It changes the fat a lot, because the fat leaves.

When I measured this, computed fat was reading 33% high across the board while protein and carbs sat within 10%. The natural experiment settled it: among recipes where almost every ingredient was priced from a database rather than guessed, the ones that involved cooking read 28.7% high on fat, and the ones that involved no cooking at all read 3.3% low. Salads were fine. Anything that met a pan was not.

The fix is a published table of retention factors. The one to use is Bognár 2002, which EuroFIR's recipe calculation guideline names as its source. Chicken keeps about 65% of its fat pan fried. Beef keeps about 75%. Mince keeps about 95%, because there is nowhere for the fat to go.

Two warnings, both of which cost me time:

USDA's own Nutrient Retention Factors table cannot help here. It carries 26 vitamins, minerals and alcohol, and no macronutrients at all. The USDA table that is relevant is a different one, Cooking Yields for Meat and Poultry.

Never apply a retention factor to a row that is already cooked. If your database entry says "chicken breast, roasted", the loss already happened. Applying the factor charges it twice.

Applying this properly took fat from 44% mean error to 32%, and the signed bias from +33% to +2%.

2. The same word means two different foods

"Rice" in a recipe means dry rice. "Rice" on a plate means cooked rice. They differ by a factor of about three.

Most databases hold the cooked row, because most databases exist for food diaries. So a recipe that says 100 g of rice, priced against a cooked row, comes out at roughly a third of the truth. Meat runs the other way: you buy it raw, and a cooked row overstates it.

The rule I ended up with, after measuring both directions:

• Meat defaults to raw, because that is how it is bought and how recipes weigh it.
• A staple only counts as dry when the recipe says so. "400 g cooked rice to serve" is cooked. "400 g rice" is ambiguous, and guessing dry priced that line at 1,460 calories against a real figure near 520.
• An ambiguous staple is better left out of the sum than guessed at. Defaulting them to dry pushed 52 of 63 test recipes high. Defaulting them to cooked was worse again.

The state word usually lives next to the quantity, not in the ingredient name. "Uncooked", "dry weight", "cooked". In my set, 21 of 90 staple lines said which they meant, and all of that information was being thrown away before the matching even ran.

3. Your database has nonsense in it, and the nonsense is large

USDA FoodData Central is the free source almost everyone uses, and it has two halves. Foundation and SR Legacy are measured in laboratories. Branded is submitted by manufacturers, and nobody checks it.

Two thirds of the lookups in my set were landing on Branded rows, and they were not slightly wrong:

• Chilli powder at 7,500 calories per 100 g. A teaspoon of it priced a recipe 1,125 calories high.
• Beef bone broth at 327 calories per 100 g, against a real figure near 30. In a soup using 720 ml, that is 2,354 calories of error in one line.

The cheap guard is physical rather than statistical: nothing edible is denser than pure fat. Oils are 884 calories per 100 g. Anything claiming more than about 900 is impossible, and rejecting those rows alone moved my mean error from 21.1% to 19.6%.

That check cannot catch the broth, because 327 is merely wrong rather than absurd. For the handful of ingredients that appear in almost every savoury recipe, broth and stock above all, it is worth keeping your own figures.

A related trap: a qualifier that reduces fat, with no row of its own, will price at the full fat row and always err high. Light coconut milk matched against regular canned coconut milk read 965 calories against about 330. Fat free sour cream reads 193 against 24.

4. A partial sum is worse than no sum

If one ingredient fails to match, you have two options. You can leave it out, or you can refuse to give a number.

Leave it out and you get results like a 900 calorie beef stew, whose tomatoes matched and whose brisket did not, reporting 9 calories a serving while looking completely confident.

Only rebuild the total from the lines when every line carries a number. Otherwise say you could not work it out. A missing answer is annoying. A wrong answer with a tick next to it is worse, because it gets planned around.

What this is actually worth

With all four handled, computed macros beat a language model's guess at the same recipes on every macro: calories 28% mean error down to 15%, protein 22% to 13%, carbs 44% to 31%, fat 42% to 33%.

That is better. It is not right. Half of recipes are still materially off, and the honest framing is that this is less wrong rather than accurate.

Which is worth saying because the number on a recipe card, yours or anyone's, is an estimate. If a figure matters to you, weigh the thing and price the ingredients yourself. The point of automating it is that nobody does that, so the realistic comparison is not against perfect, it is against the guess you would otherwise have made.

If you would rather not do this by hand

This is what MyMealStream does to a recipe you share to it from TikTok or Instagram. It reads the ingredient list, prices each line, applies the cooking losses above, and refuses to show a total when it could not price everything. The figures it shows are the ones the method above produces, with the same limitations.

Get MyMealStream if that sounds useful. If you want to do it yourself, everything above is enough to build it, and the Bognár factors are published.