Normalized power calculator
A perfectly steady ride at 200 W scores a Normalized Power of 200 W and a variability index of 1, while surges and climbs push NP above the average. Paste the power samples from your ride to see its real load. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Window
- 30
- N
- 40
- Rolling count
- 11
- Average power
- 200
- Normalized power
- 200
Normalized Power is the training-load metric cyclists and coaches use when average watts hide hard surges. A flat 200 W ride and a punchy 200 W average with repeated spikes do not cost the same physiologically; Normalized Power (NP) reweights the series with a rolling average raised to the fourth power so variable efforts score higher than steady ones. This normalized power calculator accepts an ordered list of positive power samples—typically one-hertz meter exports—applies a trailing rolling window (default thirty samples, matching the classic thirty-second window at one hertz), averages the fourth powers of those rolling means, and returns the fourth root as NP in watts, together with average power and the variability index NP divided by average power.
What Normalized Power means and why the fourth power appears
Average power is a straight arithmetic mean of every watt sample on the ride. It is easy to explain and easy to game: coasting, drafting, and short recoveries pull the mean down while brief anaerobic bursts barely move it. Normalized Power was designed so that a ride with the same average watts but more variable efforts receives a higher score that better tracks metabolic cost and perceived stress.
The method does three nonlinear steps after the samples are in hand. First, each sample is replaced by a trailing rolling average over a short window—classically thirty seconds at one-hertz sampling—so single-sample spikes are smoothed into efforts the body can actually feel. Second, those rolling averages are raised to the fourth power.
Fourth-power weighting strongly amplifies higher rolling means relative to lower ones, which is why surges and climbs dominate NP while easy spinning contributes far less. Third, the mean of those fourth powers is taken and the fourth root restores units to watts. The result is a single number, often a little above average power on variable terrain and nearly equal to average power on a steady erg set.
What to enter, the window and the results
Order matters: sample zero is the start of the series and the last sample is the end. Typical meter exports are one sample per second; if your file is resampled, keep the window consistent with your sample rate (thirty samples at one hertz equals thirty seconds; sixty samples at two hertz equals the same physical window). Optional window defaults to thirty and must be an integer from one to three thousand six hundred; the series length must be at least the window so at least one full trailing mean exists.
Optional precision sets decimal places for numeric outputs from zero to twelve, default four. An empty array, a missing powers field, a series shorter than the window, or an out-of-range window or precision also fail. Those validation failures are not billed.
Numeric strings that parse as finite decimals are accepted so CSV paste paths work without a separate parse step.
What you can do with it
Race and workout file review
Paste or upload a one-hertz power series from a race or indoor session and compare normalized power, average power, and variability index to judge how punchy the effort was.
Teaching and reproducible notebooks
Show students why fourth-power weighting lifts variable efforts above steady rides by running the same series through a deterministic NP oracle in class or CI.
FAQ
How is normalized power calculated from a power series?
Take a trailing rolling average of length window (default 30 samples), raise each rolling mean to the fourth power, average those fourth powers, then take the fourth root. That fourth root is NP in watts.
What inputs does the normalized power calculator require?
A non-empty powers array of finite strictly positive watts. Optional window (default 30) and precision (default 4). Series length must be at least the window.
What is variability index?
Values near 1 indicate a smooth effort; higher values indicate a more variable, surge-heavy file.
Which rolling window should I use?
Keep the default of 30 samples, which is the classic 30-second window for a file with one sample per second. If your file has two samples per second, use 60 to cover the same time. The ride must have at least as many samples as the window.
Can my power file contain zeros from coasting?
No. Every sample must be above zero, so zeros from coasting and negative glitches are rejected, and the message names the position of the bad sample. Remove or fix those samples before calculating.
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/health/normalized-power \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"powers":[180,200,220,190,210,250,240,200,180,170,160,200,230,250,220,200,190,180,200,210,220,240,230,200,180,170,160,150,200,250,240,220,200,180,190,210,200,190,180,200]}'const res = await fetch("https://api.kit.forhosting.com/health/normalized-power", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"powers": [
180,
200,
220,
190,
210,
250,
240,
200,
180,
170,
160,
200,
230,
250,
220,
200,
190,
180,
200,
210,
220,
240,
230,
200,
180,
170,
160,
150,
200,
250,
240,
220,
200,
180,
190,
210,
200,
190,
180,
200
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/health/normalized-power",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"powers": [
180,
200,
220,
190,
210,
250,
240,
200,
180,
170,
160,
200,
230,
250,
220,
200,
190,
180,
200,
210,
220,
240,
230,
200,
180,
170,
160,
150,
200,
250,
240,
220,
200,
180,
190,
210,
200,
190,
180,
200
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/health/normalized-power", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"powers":[180,200,220,190,210,250,240,200,180,170,160,200,230,250,220,200,190,180,200,210,220,240,230,200,180,170,160,150,200,250,240,220,200,180,190,210,200,190,180,200]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"powers":[180,200,220,190,210,250,240,200,180,170,160,200,230,250,220,200,190,180,200,210,220,240,230,200,180,170,160,150,200,250,240,220,200,180,190,210,200,190,180,200]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/health/normalized-power", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"powers": [
180,
200,
220,
190,
210,
250,
240,
200,
180,
170,
160,
200,
230,
250,
220,
200,
190,
180,
200,
210,
220,
240,
230,
200,
180,
170,
160,
150,
200,
250,
240,
220,
200,
180,
190,
210,
200,
190,
180,
200
]
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "health.normalized_power",
"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
Invalid or non-positive samples fail with invalid_input and are not billed.
What Normalized Power means and why the fourth power appears
Variability index is simply NP divided by average power: values near one mean a smooth effort; values well above one mean a punchy file. This calculator implements that pipeline deterministically with no FTP, no online map, and no training-zone database—only the series you provide and an optional window length.
Input contract, window length, response shape, and errors
POST a JSON body with powers, a non-empty array of finite strictly positive numbers in watts. On success the body returns n (sample count), window, rolling_count (how many trailing means were formed), average_power, normalized_power, variability_index, and a short formula string. Every sample must be strictly positive: zeros from coasting, negative glitches, NaN, or non-numeric strings fail with invalid_input naming the bad index. Cap the request at one hundred thousand samples so edge workers stay cheap; longer rides can be downsampled or split offline before calling the endpoint.
Where a normalized power calculator earns its keep
Failed validation does not consume balance. Keep series positive, choose a window that matches your sample rate, and you get stable NP and variability index for coaching reports, LMS labs, and edge workers without standing up a full training-analysis stack of your own. Coaches review race files and indoor workouts by comparing NP and average power side by side: a criterium with the same average watts as a tempo block should show a higher NP and variability index, and this endpoint gives that pair without opening a full analytics suite. Training platforms and amateur race organizers can call the API from a webhook when a FIT or CSV upload lands, store NP next to duration, and rank efforts more fairly than average power alone.
Integration use cases
Training platform webhooks
When a FIT or CSV lands, call the API with the watt array and store NP next to duration so leaderboards and load charts are not driven by average watts alone.
Technical questions
Why are zeros and negative watts rejected?
This endpoint requires strictly positive samples so NP is well-defined without ad-hoc zero handling. Coasting zeros should be filtered or replaced upstream; invalid_input is returned and not billed.
What does the normalized power calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.