How to Fix Podcast LUFS for Spotify and Apple Podcasts

If you publish podcasts, you've probably watched your stats dashboard and noticed something strange: the same episode plays back at different perceived volumes on Spotify and on Apple Podcasts. Sometimes the Spotify version is louder. Sometimes the Apple version is louder. The reason is that the two services normalize to different LUFS targets, and your master file is being turned up or down on each platform by a different amount.

Fixing this isn't complicated once you know what LUFS actually measures, what each platform is targeting, and the simplest two-step process that hits both targets without distorting your voice. The whole workflow runs in a free DAW you probably already have open, takes about ninety seconds per episode, and prevents the most common podcast loudness mistakes.

---

What LUFS Actually Measures

LUFS stands for Loudness Units relative to Full Scale. It's a measurement of perceived loudness, weighted to match how human hearing responds to different frequencies. A pure 1 kHz tone measures straightforwardly on a VU meter, but real audio is a mix of frequencies, and the ear is far more sensitive to midrange than to deep bass or airy treble. A signal with lots of low-end energy can read "loud" on a peak meter and still feel quiet when you actually listen to it.

LUFS solves that problem. It applies a frequency weighting (the ITU-R BS.1770 curve) that approximates human hearing, then integrates the result over the full duration of the audio. The output is a single number — the integrated loudness — that predicts how loud something will feel to a listener on average over the whole episode. Both Spotify and Apple Podcasts use this measurement (Apple calls its variant LKFS, but the math is the same).

Two related numbers are also worth knowing. True peak (dBTP) measures the actual peak amplitude of the waveform after considering inter-sample peaks — the invisible overshoots that happen when a DAC reconstructs the signal. Loudness range (LRA) measures how much the perceived loudness varies across the episode: a single-host conversational podcast might have an LRA of 4 LU, while an interview show with wildly different mic setups on each guest might hit 12 LU.

If the distinction between "average loudness" and "peak" feels familiar, it's because they're closely related to the difference between normalization and compression — the former moves the whole signal up or down, the latter attenuates moments that exceed a threshold. Podcasts need both. Our breakdown of compression vs normalization covers the full mechanics if you want the deep version.

---

What Spotify and Apple Podcasts Each Want

The two largest podcast platforms use different reference levels — and Spotify's target moved in 2024, which is why older tutorials now lead you astray.

Platform	Integrated target	True peak ceiling
Spotify (music)	-14 LUFS	-1 dBTP
Spotify (voice, since 2024)	-1 LUFS (speech)	-1 dBTP
Apple Podcasts	-16 LUFS	-1 dBTP

The key changes to know about: Spotify introduced a separate "voice" loudness target of −1 LUFS in 2024, applying it to podcast and audiobook content so spoken-word episodes stay intelligible without listeners cranking their volume. Older advice that tells you to hit −14 LUFS for podcasts on Spotify is outdated — your dialogue will go through less heavy turn-down than music, but it'll still get touched.

Apple Podcasts has held −16 LUFS as the reference for years. Apple lets podcasts ride a little quieter on average, which is why a perfectly mastered episode will sound noticeably louder on Spotify than on Apple if its integrated loudness is closer to −14 than −16.

Why two different targets at all? Each platform's loudness recommendation is calibrated to its own playback context — Apple's target fits how listeners tend to consume podcasts (often with music or environmental noise in the background), and Spotify's voice target prioritizes dialogue punch for mobile listening. Neither is wrong. They're aiming at different perceptual goals.

---

The 2-Step Fix That Hits Both Targets

Here's the most reliable workflow for getting every episode to play correctly on Spotify voice mode and Apple Podcasts (and also YouTube, which targets −14 LUFS, and standard Spotify music mode, which targets the same −14): the limiter-then-normalizer approach. Order matters: peak limit first, then target loudness. Doing them in the opposite order causes clipping or muffled voice.

Step 1 — True peak limit to −1 dBTP

Before you touch loudness, slap a brick-wall limiter on your master bus with the ceiling at -1 dBTP. This catches every inter-sample peak and any transient that would clip on the worst-case DAC or encoder. Both Spotify and Apple reject or distort files that exceed this ceiling, so getting it right here prevents the whole pipeline from breaking downstream.

Set the limiter's release so it doesn't pump — for spoken word, a release of around 100–200 ms works well. The attack should be fast enough to catch plosives and laughs (1–5 ms is typical). Don't worry about loudness yet; the limiter is purely there to guarantee nothing above −1 dBTP survives.

Step 2 — Loudness-normalize to −16 LUFS (Apple's target)

Now apply a loudness normalizer with the target set to -16 LUFS (Apple's reference). Run the analysis on the entire episode, and apply the calculated gain. Every free DAW — Audacity, Reaper, GarageBand, Hindenburg, Auphonic — has a LUFS meter and a normalization function that does this in one or two clicks.

Why Apple and not Spotify? Because −16 LUFS is the quieter of the two targets. When you master to −16 LUFS, your episode plays back at full intended loudness on Apple Podcasts (no turn-down, no turn-up), and on Spotify either the music-mode normalizer pulls it up by ~2 LU to reach −14 LUFS, or the voice-mode normalizer pulls it up dramatically to hit −1 LUFS, both of which are louder — never quieter. Your listeners will hear the episode at or above intended level on every major platform, never below.

The opposite — mastering at −14 — would put Apple Podcasts listeners at −2 dB below Spotify, which is the loudness gap you started out trying to fix. Master to −16, and both platforms converge on what your master sounds like.

---

How to Measure LUFS in a Free DAW

You don't need a paid plugin suite to do this. Three widely-available free tools all support the ITU-R BS.1770 LUFS measurement and apply normalization correctly:

• Audacity — open source, free. Use Effect → Loudness Normalization (built-in since Audacity 3.2). Set the target to −16 LUFS, check "Normalize peak amplitude" to −1 dBFS as a safety pass — or do that with a separate limiter first, as in the 2-step approach above. Hit "Preview" to see the integrated loudness, then "OK" to apply.
• Reaper — free for evaluation indefinitely. Install the free Youlean Loudness Meter plugin (VST) and load it on your master bus to see integrated LUFS, true peak, and LRA in real time.
• Auphonic Web Service — paid at volume but free for two hours of audio per month. Drop in your episode, select podcast preset, and it returns a mastered file at −16 LUFS with a brick-wall limiter at −1 dBTP already applied.

For Visually-oriented workflows — the kind where you want to see the integrated LUFS reading while you tweak — Reaper with Youlean is probably the friendliest. For a single batch of episodes, Audacity's loudness normalization effect is the fastest path.

The common mistake across all three is forgetting the limiter-first step. If you raise a quiet episode by, say, 8 dB to hit −16 LUFS without first limiting peaks, every plosive in your dialogue clips on Apple Podcasts' encoder. Always limit first. Always.

---

How SoundBound Helps You A/B-Test the Result

After you export the mastered file, the next question is: does it actually sound right to your ears? That's where SoundBound comes in — not as a replacement for your DAW's mastering workflow, but as a fast way to preview how your episode will play back at common consumer settings without leaving the browser. SoundBound applies both normalization and compression in real time across any browser tab, which means you can drop your exported episode into a SoundBound session and audition it at the same loudness ceiling a Spotify listener using earbuds in a noisy environment will actually hear it at.

It also serves the other half of the workflow: if you've ever wondered why a podcast that sounds fine in your studio arrives at a listener as too quiet (or too loud), the answer usually lies in how their playback chain interacts with the platform's normalization curve. SoundBound makes that interaction visible. The same family of concerns — why YouTube's loudness normalization doesn't always save you, why platform targets disagree, why some episodes arrive "hotter" than others — are covered in our YouTube normalization guide if you publish video versions of the same content.

And if you spend enough time A/B-testing your own episodes this way, you'll start noticing the same problem every platform tries to solve: the loudness target isn't a moral standard, it's a perceptual compromise. Picking −16 LUFS as your master target is just the least-bad solution across the current odd-numbered targets; the day a platform moves to a different reference, the workflow has to move with it. Two-step mastering — limit first, normalize second — survives those moves without forcing a re-think of the whole pipeline.

---

Common Podcast Loudness Mistakes

A few specific traps that podcast creators fall into even after they understand the targets:

Mastering below −19 LUFS

The thinking goes: "I'll under-master so platforms turn me up and I'll sound louder than everyone else." The opposite happens — Apple Podcasts caps its turn-up at about +3 dB beyond its target, and Spotify voice mode caps at roughly +2 dB before applying compression to restore target. Your episode gets turned up by the limiter and the compression smears your dialogue. The cure is to master at the target, not 5 dB below it.

Limiting after loudness normalization

Apply the limiter to your original quiet master first, gain it up to leave headroom, then measure and normalize. If you normalize first and then add a limiter, the limiter will squash whatever peaks remained and you'll lose transient detail without ever realizing why. Order is everything.

Ignoring true peak for sample peak

dBFS and dBTP aren't the same. A file that peaks at −0.3 dBFS on a digital meter can have inter-sample peaks that touch 0 dBTP (and beyond, after a DAC), causing audible distortion on consumer playback. Always set your limiter ceiling at −1 dBTP, not −1 dBFS.

Publishing a separate master per platform

Tempting, but unnecessary. The 2-step workflow above produces one file that plays back reasonably on every major destination. Maintaining separate −14 and −16 masters doubles your work for marginal benefit; the platforms are normalizing anyway.

---

The Practical Workflow Recap

To put the whole thing on one line: limit your master to −1 dBTP, then loudness-normalize to −16 LUFS, then export. That single sequence satisfies both Spotify's voice mode and Apple Podcasts' integrated-loudness target, plus YouTube, plus standard Spotify music-mode normalization, with no clipping, no smear, and no re-encoding.

If you want to verify before publishing, drop the exported file into SoundBound — apply your normal consumer ceiling (something like −14 dBFS for earbuds at moderate volume) and listen to a minute of dialogue plus a minute of loudest peak. If both play back comfortably within the ceiling with headroom, you're done. If dialogue sounds thin, your limiter is too aggressive; if a laugh still feels too hot, your limiter release is too short.

That's the whole craft. Most podcast loudness problems are about order of operations alone — limit before normalize, target the louder platform's preferred ceiling as your master, measure with ITU-R BS.1770, and trust the platform normalizers to do their job. The remaining ten percent is listening.

---