Loudness normalization gain calculator
A master measured at -18.2 LUFS needs +4.2 dB to reach the -14 LUFS streaming target. Enter your meter reading and choose a target such as broadcast at -23 LUFS or podcast at -16 to see the exact gain and its direction. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Measured lufs
- -18.2
- Target standard
- streaming
- Target lufs
- -14
- Gain db
- 4.2
- Direction
- increase
This loudness normalization gain calculator turns an integrated loudness measurement into a precise level adjustment. Enter the measured LUFS value from your meter and select a recognized delivery target, such as -14 LUFS for general streaming or -23 LUFS for broadcast. The result shows how many decibels to add or subtract, the resolved target, and the direction of the change. It is deterministic arithmetic, so it is useful in repeatable mastering checks, automated quality-control reports, and audio publishing workflows without uploading or processing the audio itself.
Measure integrated loudness before calculating gain
Start with an integrated loudness reading for the complete program, episode, song, advertisement, or other finished segment. Integrated LUFS describes average perceived loudness across the measured interval, so it is more suitable for delivery normalization than a momentary reading captured during one loud passage. Use a meter that follows the relevant loudness measurement method, analyze the intended program boundaries, and enter its signed value exactly; typical measurements are negative.
For example, a master measured at -18.2 LUFS is quieter than a -14 LUFS target. This calculator does not inspect an audio file or verify the meter reading. It accepts the measurement as supplied and isolates the gain calculation from decoding, metering, limiting, and encoding.
That separation makes the result easy to reproduce in a script or quality-control system. If intros, advertisements, silence, or alternate edits are included in the measurement window, they can change integrated loudness, so use the same program boundaries that your delivery specification expects before treating the calculated adjustment as authoritative.
Understand the signed gain result
The calculation is target LUFS minus measured LUFS. If audio measures -18.2 LUFS and the streaming target is -14 LUFS, the result is +4.2 dB, meaning the nominal level must increase by 4.2 dB. If a program measures -20 LUFS and the broadcast target is -23 LUFS, the result is -3 dB, meaning it must decrease by 3 dB.
A zero result means the measured integrated loudness already equals the selected target. LUFS and decibels describe different things, but a uniform gain change shifts the integrated loudness by the same numerical amount when no nonlinear processing intervenes. The response therefore labels the direction as increase, decrease, or none and also returns the target value used.
Apply the signed gain in a digital audio workstation, transcoding pipeline, or mastering system, then meter the rendered result again. Re-measurement matters because clipping protection, a limiter, dynamics processing, lossy encoding, or a changed program boundary may prevent the final integrated reading from moving by exactly the requested amount.
Choose a recognized delivery target
Select the standard that matches the actual destination rather than assuming every service uses the same reference. The general streaming, Spotify, and YouTube presets resolve to -14 LUFS; podcast and Apple Music presets resolve to -16 LUFS; broadcast and EBU R128 resolve to -23 LUFS; and ATSC A/85 resolves to -24 LUFS. These presets make automated requests explicit and prevent a misspelled or invented destination from quietly producing a misleading adjustment.
An unrecognized target returns an invalid-input error with the supported names. A named target is a calculation reference, not a guarantee that a distributor will leave playback untouched: services may update policies, normalize only under certain conditions, or use additional peak constraints. Check the current delivery specification when compliance matters.
Loudness is also only half of safe normalization. Before applying positive gain, inspect true peak headroom and use appropriate limiting if the result would exceed the required ceiling. This capability deliberately reports gain rather than predicting peaks, preserving dynamics, or deciding whether a master is artistically appropriate.
What you can do with it
Prepare a streaming master
Convert a measured integrated LUFS value into the signed gain needed for the general -14 LUFS streaming target.
Check broadcast delivery
Calculate the reduction or increase required for an EBU R128 -23 LUFS or ATSC A/85 -24 LUFS handoff.
Automate podcast quality control
Add a deterministic -16 LUFS target comparison to episode reports without sending audio to another service.
FAQ
What formula does the calculator use?
Positive values increase level; negative values decrease it.
Does this tool measure my audio?
No. Supply an integrated LUFS measurement from a loudness meter; this capability only computes the gain adjustment.
Which target standards are recognized?
Streaming, Spotify, and YouTube use -14 LUFS; podcast and Apple Music use -16; broadcast and EBU R128 use -23; ATSC A/85 uses -24.
Will applying the result guarantee compliance?
Not by itself. Re-measure the rendered output and check true peak, program boundaries, and the destination's current specification.
Why should I measure again after applying the gain?
A limiter, clipping protection, other dynamics processing, lossy encoding or a changed program length can stop the final reading from moving by exactly the requested amount. Meter the rendered file once more before delivery.
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/audio/normalize-loudness \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"measured_lufs":-18.2,"target_standard":"streaming"}'const res = await fetch("https://api.kit.forhosting.com/audio/normalize-loudness", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"measured_lufs": -18.2,
"target_standard": "streaming"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/audio/normalize-loudness",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"measured_lufs": -18.2,
"target_standard": "streaming"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/audio/normalize-loudness", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"measured_lufs":-18.2,"target_standard":"streaming"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"measured_lufs":-18.2,"target_standard":"streaming"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/audio/normalize-loudness", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"measured_lufs": -18.2,
"target_standard": "streaming"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "audio.normalize_loudness",
"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.
Limits
max_mb | 200 |
max_minutes | 180 |
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 questions
What happens for an unknown standard?
The request fails with an invalid_input error instead of selecting a default target.
What does the API request cost?
Each API request costs $0.002; the browser version is free.