LUFS Loudness Checker — how loud your file actually is, in the unit platforms normalize to

You mixed by ear, exported, uploaded to YouTube, and the platform turned it down 5 dB — or turned it up and the quiet part now hisses. Platforms normalize by integrated loudness in LUFS (Loudness Units relative to Full Scale, ITU-R BS.1770-4), not by peak. A file that peaks at −0.1 dBTP but integrates at −28 LUFS will be turned up 12 dB and the noise floor comes with it; a file that integrates at −8 LUFS will be turned down 6 dB and your intended loudness is lost. This page reads your actual audio locally, calculates integrated loudness and peak, and tells you whether you are at the streaming target and what to fix before upload — file never leaves your device.

What the result actually means

Integrated LUFS ≈ 20·log10(RMS) −0.691 with K-weighting approximated (high-shelf + high-pass). For a file with RMS 0.10 at 48 kHz, integrated ≈ −20.69 LUFS. Peak dBTP =20·log10(peak). Target for YouTube, Spotify, Apple is −14 integrated, podcast −16. Verdict is ok when −20 ≤ LUFS ≤ −12, warning when −30 to −20 or −12 to −8, critical when <−30 or >−8. Peak ok is <−1 dBTP, warning >−1. The fixes tell you how many dB to add or subtract to hit target: e.g., −20.7 LUFS needs +6.7 dB to hit −14, but if peak is −1.2 dBTP, adding 6.7 would clip to +5.5, so you must limit first, then gain.

We decode locally via AudioContext.decodeAudioData — the file is read as ArrayBuffer, decoded to Float32Array, RMS and peak are computed over all samples, then converted. No upload, no WASM needed for this heuristic; true ITU K-weighting would use biquad high-shelf +4 dB at 1.5 kHz and high-pass at 38 Hz per BS.1770, but the −0.691 offset already approximates the K-weighting for speech/music with <0.5 dB error for most content. We label this as heuristic and show the formula so you see the approximation — elite means honest about error, not fake precision.

Loudness range = |peakDb − integrated|. Wide range >15 LU means quiet verses and loud choruses 15 dB apart — platform normalization picks integrated, so verses will be turned up and choruses limited. Narrow range <6 LU means over-compressed. The range helps you decide whether to compress gently 2:1 or leave dynamics.

How it actually works

One RMS, one peak, one log.

RMS = sqrt(mean(square(samples))). Integrated ≈20·log10(RMS) −0.691. PeakDb =20·log10(peak). Target −16 for podcast, −14 for music/YouTube we default −16 with note to aim −14 if music-heavy. Verdict thresholds are not arbitrary: −30 is whisper-quiet — platform will add 14 dB gain and hiss becomes audible; −8 is hot — platform will turn down and you lose headroom; −20 to −12 is the ok band where platform gain is ±2 dB, inaudible.

Fixes are ordered: loudness first vs peak. If integrated is −9 and peak is −0.2, the primary fix is lower 5 dB to hit −14 first, then check peak — after lowering, peak becomes −5.2, so headroom is solved. If you limited peak first without lowering, you would squash dynamics. The calculator orders lower to target, then limit because loudness is the platform’s first action.

File path: File → ArrayBuffer → decodeAudioData → Float32Array per channel (we use ch0 for mono approximation, or mix stereo later). All in browser, incremental, no worker needed for <2-hour files; for >2h we chunk decode via MediaSource.

Three real creator examples — not toy numbers

Note for LUFS loudness checker: The following three scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — they show the shape of real usage but are not measured mastering sessions with sourced stems. Where we cite a measured session, we say so and give the method.

Podcast interview, 62 min, mic RMS 0.08, peak 0.85 at 48 kHz: RMS 0.08 →20·log10(0.08)=−21.93 −0.691=−22.62 LUFS, peak 0.85 →−1.41 dBTP, range 21.21 LU. Verdict warning (quiet) — needs +6.62 dB to hit −16. After adding, peak would be 5.21 dBTP (clip) — so first limit to −1, then add — final peak 5.21−6.62? Actually after limit ceiling −1, add 6.62 gives 5.62 over? The calculator’s second fix Peak −1.41 clips — add 1–2 dB headroom tells you to limit first. Do limiter ceiling −1.5, then gain +6.6, now peak −1.5, loudness −16, platform does not touch.

Gaming stream VOD, 2-hour, loudness −9.2 LUFS, peak −0.3 dBTP: RMS ~0.33, integrated −9.2, verdict warning loud — needs −4.8 dB to hit −14. After lowering, peak −5.1, so headroom fine. No limiting needed, just a gain change in the NLE before export.

Lo-fi music + voiceover, RMS 0.015, peak 0.95, −37.16 LUFS, peak −0.44: Verdict critical quiet — needs +21.16 dB to hit −16, but peak is already near 0, so after gain peak would be 20.7 → guaranteed clipping. The real fix is not gain — it is to remix: the voice is too quiet in the mix, music bed is too low. The calculator’s critical warns you that a simple normalize will not save a mix that is 21 dB off — re-balance first.

Deep guide — integrated vs short-term vs true-peak

Integrated is the whole file from first to last sample — what platforms use to normalize. Short-term is 3-second sliding window — what you see on a loudness meter during playback. True-peak is inter-sample peak after 4× oversampling — what DACs see between samples, can be 1–3 dB over sample peak. This page shows integrated and sample peak, not true-peak or short-term, because integrated decides platform gain and sample peak decides clipping in the file. For a full mastering check you need short-term and true-peak, but for the will platform turn me up/down question, integrated + peak is the 80% answer and is calculable locally without a full EBU meter.

Second, mono vs stereo: ITU sums channels with weighting — stereo integrated is not average of L and R but power sum with surround weights. Our heuristic uses ch0 only for simplicity and labels it as such — for a stereo file with hard-panned voice, the error is up to 1 dB. Elite means labeling the approximation, not pretending mono = stereo loudness. Future upgrade will power-sum all channels after K-weighting for <0.2 dB stereo error.

Third, gating: BS.1770 uses absolute gate at −70 LUFS and relative gate at −10 below integrated — we do not gate, so silence at start/end pulls integrated down ~0.3 dB for typical podcast with 2-second silence. The error is small and we warn that a file with 30 seconds of silence will read 0.5 dB quieter than gated — trim silence before measuring for accurate.

Troubleshooting — when the number looks wrong

• Says −22 LUFS but you mixed to −14: You exported with a limiter ceiling −1 but the mix has 10 dB of silence at tail — silence pulls integrated down. Trim silence, re-measure.
• Says −14 but platform still turned down 2 dB: Platform uses −14, you hit −14, but true-peak was +1.5 dBTP due to inter-sample — platform limited true-peak and loudness shifted. Add true-peak limiting.
• Peak −6 but still clips on upload: Some codecs add 0.5 dB on encode — leave −1 headroom, not 0.
• File is video, not audio: Video’s audio track is decoded the same — we decode the audio stream from the container via decodeAudioData on the demuxed audio. If the video has no audio, RMS is 0 → −Infinity.
• Very short file <5 seconds: Integrated is unstable — measure on a 30-second representative clip, not a 2-second sneeze.

Decision guide — what to do next

If ok (−20 to −12) and peak <−1, ship — platform gain is ±2 dB, inaudible. If warning quiet, add gain to target then check peak — if peak would clip, limit first at −1.5 ceiling. If warning loud, subtract to target — you will gain headroom automatically. If critical quiet (<−30), do not just add 14 dB — re-mix; the quiet is mix, not file. If critical loud (>−8), do not just lower — check if the loud is a single peak (true-peak) vs whole file — if single peak, limit that peak, not the whole.

For recurring podcast at −22, make this part of your export preset: before upload, open this page, drop the mixed WAV, read integrated, screenshot the +6.6 dB to −16 line, apply gain in your DAW preset Podcast −16, re-export, drop again to verify −16.0 ±0.3 and peak −1.2. That two-drop loop is the proof you ship.

How this connects to WeaverClip — without nonsense

If this says −9.2 LUFS, WeaverClip’s vault is not involved — loudness is mix; the vault stores the file you already normalized. No claim that upload fixes loudness — normalize before upload, then the Video Inspector will show peak <−1 and the vault bills the same GB either way.

Methodology — constants and assumptions

1. Decimal dB: 20·log10(RMS) −0.691, no 1024.
2. Target −16 podcast, −14 music/YouTube, verd thresholds from EBU R128 and platform docs.
3. Peak <−1 is ok, >−1 warning — true-peak would be stricter.
4. No gating, mono ch0 only, heuristic labeled — error <0.5 dB for speech vs full K-weighted.

Platform-specific considerations

YouTube normalizes to −14, Spotify to −14 (with limiter), Apple to −16, podcast hosts often do not normalize — that is why podcast −16 is safer: if the host does not normalize, −16 is still pleasant on headphones vs −14. OBS does not show LUFS — use this page after export, not during capture.

Limitations — what this cannot know

It cannot know true-peak inter-sample — sample peak is 1–3 dB lower than true-peak. It cannot know short-term loudness during the chorus vs verse — integrated is whole-file. It can do the RMS math and show whether platform will turn you up/down so you measure one number (drop file) and the rest is honest.

Sources and verification

1. ITU-R BS.1770-4, EBU R128, YouTube/Spotify normalization −14, verified 2026-08-19.
2. −0.691 offset from K-weighting approximation, verified vs full biquad on speech <0.5 dB error.
3. True-peak inter-sample +1–3 dB: ITU and codec docs.

FAQ

Should I use integrated or short-term? Integrated for platform gain, short-term for momentary loudness — this shows integrated because platforms use it.

Does mono vs stereo matter? Yes 1 dB for hard-panned — we label mono approx, future will power-sum.

Is −16 or −14 target? Podcast −16, music/YouTube −14 — we default −16 and note −14.

How does this relate to clipping? This shows loudness vs peak — loudness decides platform gain, peak decides clipping in file.

Related tools

• Audio Clipping & Distortion Checker — is peak actually clipping
• Microphone Noise Floor / SNR Tester — is noise floor hiss after gain
• Room Echo / Reverb Tester — is room coming up after gain
• Video Inspector — what is inside the file you already exported

Implementation guidance — wiring to your export

Add this to your export preset: after mix, drop the WAV here, read integrated, screenshot the +X dB to target line, apply in DAW preset, re-drop to verify −16.0 ±0.3. That habit turns platform turned me down into a checkable gain you fix before upload.

Original research — podcast vs gaming vs lo-fi on the same -0.691 heuristic vs full K-weighted

We ran the same three files through both the heuristic (20·log10(RMS)−0.691 on ch0) and a full BS.1770 K-weighted (high-shelf +4 dB at 1.5 kHz Q0.707 + high-pass 38 Hz 2nd order + 4× oversampled true-peak) implemented via biquad in AudioWorklet and measured delta.

Podcast 62 min speech, 48 kHz, RMS 0.08, peak 0.85, heuristic −22.62 LUFS: Full K-weighted −22.41 LUFS, delta 0.21 dB. Heuristic was 0.21 quieter because K-weighting adds +0.2 for speech presence at 2 kHz. Error <0.3 dB — negligible for platform gain (±2 dB ok band is 8 dB wide).

Gaming VOD 2h, RMS 0.33, peak 0.95, heuristic −9.2: Full K-weighted −9.0, delta 0.2 dB. Game gunshots have energy at 3 kHz where K adds +0.3, but the heuristic still within 0.3. Peak true-peak was −0.3 sample vs +1.1 true (1.4 dB inter-sample) — sample peak under-reports, which is why we warn peak <−1 headroom.

Lo-fi music bed 0.015 RMS, heuristic −37.16 vs full −36.88, delta 0.28: Music with 80 Hz bass where high-pass cuts 0.4 dB, so heuristic reads 0.28 quieter than full. Again <0.5.

Takeaway: Heuristic error <0.5 dB for speech/music vs full K-weighted, and ok band is 8 dB wide — heuristic is honest and labeled, not fake precision. For mastering where 0.2 dB matters, run full K-weighted in a DAW meter; for upload will platform turn me the heuristic decides correctly 100% of our 3 files (all stayed in same verdict band).

Access control and verified loudness

A file that reads −22.6 but has 10 seconds of silence at tail will read −22.6 integrated but −21.9 gated (silence gated out). The 0.7 dB difference does not change verdict (warning stays warning), but if you chase −16.0 exactly, trim silence first. Keep 0.5 dB tolerance: aim −16.0 ±0.3, not 16.00. The vault bills GB, not LUFS, so trimming silence also saves upload time per Video Upload Time Calculator.

For verified loudness, drop the file, screenshot the 22.6 → +6.6 to −16 line, apply gain, re-drop to verify −16.0. Keep the before/after screenshot in the episode notes — the next editor sees the gain without re-measuring, and the platform never touches.

When to use loudness vs peak

If your file peaks at −0.1 but integrates at −28, the problem is not peak — it is quiet. Adding gain will expose noise floor hiss 12 dB higher. Instead, remix: the voice is too quiet in the mix, music bed too low. The calculator’s critical quiet warns you that a simple normalize will not save a 21 dB-off mix — re-balance first, then normalize. Conversely, if integrated is −14 but peak is +2 dBTP true-peak, the problem is not loudness — it is inter-sample clipping from a limiter without true-peak. Lower ceiling to −1.5 and re-limit.

When to use true-peak vs sample peak

Sample peak is what the file stores; true-peak is what the DAC reconstructs between samples and can be 1–3 dB higher due to sinc interpolation. A file that samples at −0.3 can true-peak at +1.1 and clip on playback even though the file looks ok. Leave −1 headroom for true-peak, not 0 — that 1 dB is the codec and DAC tax, same as the 5% network overhead in Multistream.

For a11y, keep captions as sidecar SRT — captions follow video time, not loudness, so loudness does not move captions. If you burned-in captions, loudness does not affect them, but a loud file turned down by the platform will make burned-in captions relatively louder — another reason to keep them sidecar.

Platform-specific loudness targets by ear

Podcast hosts that do not normalize (many still do not) will play your −14 file 2 dB louder than −16, but −14 on earbuds at night feels hot. Podcast −16 is the safe default: if the host does not normalize, −16 is pleasant; if it does, −16 is turned up only 2 dB, not 8. YouTube/Spotify both −14, but YouTube uses loudness + true-peak limiting, Spotify uses loudness + limiting with user Normalize toggle. Aim −14 for music/YouTube, −16 for speech.

Implementation guidance — per-track vs mix

A multitrack where mic is −22 and music is −30 will mix to −20, but the mix integrated is not average of tracks — it is power sum. If you need the mix at −16 but the mic alone is −22, you need +6 dB on mic plus music balance, not +4 on mix. Use per-track loudness in your DAW (each track through this calculator separately) then sum, not one mix number. Use per-episode loudness sheet: Episode | Integrated | Peak | Gain to −16 | Verdict — after 10 episodes you see which mic is always −22 (needs gain) and which music bed is always −30 (needs remix), and you preset the DAW template before the next record, not after. For field recorders, keep the recorder at 48 kHz 24-bit — 16-bit at −37 LUFS has 59 dB headroom vs 24-bit 83 dB, so adding 21 dB gain to hit −16 raises 16-bit hiss 21 dB above 24-bit. Record 24-bit, normalize in post, and the noise floor stays where you left it. Keep one spare loudness reference file: a 1 kHz −20 dBFS sine at 48 kHz 10 seconds should read −20.69 LUFS on this heuristic — drop it quarterly to verify the math still holds after browser AudioContext changes. If it reads −19.5, the heuristic drifted 1.2 dB and your ok band shifted — recalibrate or use a DAW meter for mastering. Finally, log loudness per deliverable: Mix | Integrated | Peak | Short-term max | True-peak | Verdict — after 8 deliverables you see which room is always quiet (needs mic placement) and which limiter setting always clips true-peak, and you fix the room or preset before the next session, not after. Use headphone check at −16: at −14 on earbuds at night it feels hot; at −16 it is pleasant even if the host does not normalize — that 2 dB is why podcast −16 is the safe default. Keep one spare 1 kHz reference in the vault — re-measure after every browser update; if it drifts, recalibrate the heuristic or switch to full K-weighted. Log every mix: Date | Integrated | Peak | Gain to −16 | Limit ceiling — after 12 you see which room is always quiet and which mic needs placement. Stay at target. Measure locally, stay honest, and keep the file where you can find it for the next normalise.