Macro calculator
Split a daily calorie target into protein, carbohydrate and fat: 2000 kcal at 30/40/30 gives 150 g of protein, 200 g of carbs and 66.7 g of fat. Choose your own percentages, as long as they add up to 100. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Daily calories
- 2,000
- Protein (%)
- 30
- Carbohydrates (%)
- 40
- Fat (%)
- 30
- Protein (g)
- 150
Splits a daily calorie total into protein, carbohydrate and fat, returning grams and kcal for each from percentage inputs, using 4 kcal/g for protein and carbs and 9 kcal/g for fat.
From calories to grams in two steps
A macro plan starts with one number, your daily calorie target, and three shares that say how much of it comes from protein, carbohydrate and fat. First, each share is applied to the total: with 2000 kcal and the default split of 30, 40 and 30 percent, that gives 600 kcal of protein, 800 of carbohydrate and 600 of fat. Second, energy becomes weight using the standard factors of 4 kcal per gram for protein and carbohydrate and 9 kcal per gram for fat. The result is 150 g of protein, 200 g of carbohydrate and 66.7 g of fat.
Common mistakes when splitting macros
Dividing every share by 4 is the classic error: fat carries more than twice the energy per gram, so treating it like protein overstates the grams. Percentages that do not add up to exactly 100 are another, and here they are rejected rather than silently stretched, so a typo cannot hide inside a plan. Each share must be between 0 and 100 and the calorie target must be above zero. Results are rounded to one decimal by default, and you can choose between zero and two decimals.
What you can do with it
Nutrition and diet apps
Turn a user's calorie goal and chosen macro ratio into a gram-by-gram daily plan without shipping the formula into the client.
FAQ
What happens if I only send calories?
It uses the default 30% protein, 40% carbohydrate and 30% fat split, so a single calories value returns a full macro breakdown.
Why don't grams times four match the kcal exactly?
Grams and kcal are each rounded independently from the unrounded energy value, so their rounded forms may differ slightly by design.
How do I work out grams of protein from calories?
Multiply the calorie target by the protein share and divide by 4, the energy in each gram. With 2000 kcal and 30 percent protein, that is 600 kcal, or 150 g of protein a day.
Why is fat divided by 9 and not by 4?
Because each gram of fat supplies 9 kcal, while protein and carbohydrate supply 4. That is why 600 kcal of fat is only 66.7 g, against 150 g for the same energy from protein.
What if my percentages do not add up to 100?
The plan is refused instead of being quietly rescaled. A split such as 30, 40 and 29 fails, so adjust one of the shares until the three total exactly 100 and try again.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev/macro-calculator \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"calories":2000}'const res = await fetch("https://api.kit.forhosting.com/dev/macro-calculator", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"calories": 2000
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/macro-calculator",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"calories": 2000
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/macro-calculator", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"calories":2000}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"calories":2000}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/macro-calculator", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"calories": 2000
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.macro_calculator",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
How the split is computed
With the defaults of 30/40/30 on a 2000 kcal target this yields 600, 800 and 600 kcal, which become 150 g protein, 200 g carbohydrate and 66.7 g fat, exactly matching the shipped example. It multiplies calories by each percentage over 100 to get protein_kcal, carb_kcal and fat_kcal, then converts energy to mass using the Atwater factors: grams = kcal / 4 for protein, kcal / 4 for carbohydrate, and kcal / 9 for fat. The response echoes the calorie total and the three percentages so a caller can store the full macro plan from a single request without recomputing anything client-side.
Percentages, defaults and the sum-to-100 rule
protein_percent defaults to 30, carb_percent to 40 and fat_percent to 30, so passing only calories returns a balanced split. Each percentage must be a finite number between 0 and 100 inclusive, checked field by field, and an out-of-range value throws invalid_input naming that field. The three shares must sum to 100 within a 1e-9 tolerance; if they do not, the call fails with the message that the percentages must add up to 100. That tolerance is deliberately tight, so 30/40/30 passes but 30/40/29 is rejected rather than silently rescaled. calories itself must be a finite number strictly greater than zero.
Rounding and the six numeric outputs
The optional decimals parameter defaults to 1 and must be an integer from 0 to 2; anything else raises invalid_input. Because grams and kcal are rounded separately, protein_g times 4 will not always re-derive the rounded protein_kcal; both figures come from the unrounded energy value. After rounding, every numeric field is re-checked for finiteness and a non-finite result throws invalid_input, so the output is always a clean, fully-populated JSON object with all six macro numbers present.
Integration use cases
Meal-prep and coaching tools
Generate protein, carb and fat targets for many clients at once via the API, each with their own percentage split.
Fitness content and calculators
Embed the free widget so visitors can experiment with ratios like 40/40/20 and see grams update deterministically.
Technical questions
What calorie-per-gram factors are used?
4 kcal per gram for protein and carbohydrate and 9 kcal per gram for fat, the standard Atwater conversion applied in lib.js.
Do the percentages have to add up to 100?
Yes. protein_percent, carb_percent and fat_percent must sum to 100 within 1e-9 or the call returns an invalid_input error.
Is it free and what does the API cost?
The browser widget is free (tier A) and runs the identical core; API calls are billed per successful request from $0.002.