What loudness does Spotify want for podcasts?
Spotify normalises podcast playback to roughly −14 LUFS. Louder episodes are turned down automatically. You do not gain anything by delivering hotter than −14 LUFS — it only costs you dynamics.
Learn
Podcast loudness on Spotify, Apple Podcasts & YouTube
Spotify normalises podcasts to about −14 LUFS, Apple Podcasts asks for −16 LUFS ±1, and YouTube plays back near −14 LUFS. What the platforms actually do, and the one target that is safe everywhere.
The short answer
Deliver −16 LUFS integrated with a true peak at or below −1 dBTP and every major platform is happy: it matches Apple's published requirement exactly, and Spotify and YouTube normalise playback anyway — they turn louder files down, so pushing past −16 gains you nothing.
What each platform actually does
| Platform | Loudness behaviour | Published target |
|---|---|---|
| Apple Podcasts | Publishes a delivery spec; expects you to hit it | −16 LUFS ±1, ≤ −1 dBTP |
| Spotify | Normalises playback; louder audio is turned down | ≈ −14 LUFS, ≤ −1 dBTP |
| YouTube | Normalises playback down toward ≈ −14 LUFS; never boosts | No formal podcast spec |
The pattern: platforms protect listeners from loud content reliably, but protect you from quiet content only partially — boosting risks clipping, so it is done conservatively or not at all.
Why one target beats per-platform masters
It is tempting to export a −14 LUFS version for Spotify and a −16 LUFS version for Apple. In practice that doubles your workflow for zero audible benefit: on every platform that normalises, both files play back at the same perceived volume. What listeners do notice is inconsistency between episodes — a back catalogue that jumps around in loudness. One consistent target, checked on every episode before publishing, fixes that.
−16 LUFS is the right single target for spoken word because it is the only number with a hard published requirement behind it (Apple's), and the normalising platforms treat it exactly like anything louder. See what LUFS should a podcast be for the measurement itself.
The part everyone forgets: true peak
All the platform specs pair the loudness number with ≤ −1 dBTP. That headroom exists because lossy encoding (the MP3/AAC step every platform applies) can push inter-sample peaks above the highest sample value. A file that measures 0 dBFS clean can distort audibly after encoding. Normalising loudness without checking true peak is only half the job.
How to check before you publish
- Measure the integrated loudness of the final episode file — the whole file, not a loud section.
- Confirm −16 LUFS ±1 and true peak ≤ −1 dBTP.
- If it misses, normalise (two-pass loudness normalisation, not just gain) and re-measure the corrected file.
If you publish on WordPress, AudioLinter runs exactly this check in the post editor: it measures LUFS and dBTP on every episode, flags anything outside the target range, and (on Pro) repairs loudness with two-pass EBU R128 processing in one click — then re-analyses the result.
Frequently asked questions
What loudness does Apple Podcasts require?
Apple's audio requirements ask for −16 LUFS integrated loudness (±1 dB) with a true peak no higher than −1 dBTP. This is the strictest published podcast spec among the major platforms.
Should I master my podcast to −14 or −16 LUFS?
−16 LUFS is the safer single target for spoken word: it meets Apple's spec exactly, and Spotify and YouTube simply normalise it on playback. Delivering −14 LUFS violates Apple's ±1 dB window while gaining nothing on the platforms that normalise anyway.
Do platforms make quiet podcasts louder?
Only partially. Turning content down is always safe, so every platform does that. Boosting quiet audio risks clipping, so it is applied conservatively or not at all — a too-quiet episode usually stays too quiet. Fixing loudness before publishing is the only reliable way.