Podcast loudness standards: why one export at -16 LUFS beats a master per platform
Apple Podcasts is the only major listening platform we could find that publishes a loudness requirement for episodes. The others re-level at playback, which is why one export at -16 LUFS and -1 dBTP is enough.
Nihar Rout · · Updated · 10 min read · 12 views
Podcast loudness standards come down to two numbers you set once: -16 LUFS integrated and a true peak no higher than -1 dBTP. Apple Podcasts is the only major listening platform we could find that publishes a loudness requirement for episodes. The others adjust the level at playback instead of rewriting your file, so in our view a separate master per platform is wasted work.
What follows is what each platform's own documentation says, where the -14 LUFS figure in every loudness blog post actually comes from, the one place the number legitimately changes, and a short export pass you can run on every episode. We read every page linked here on October 23, 2026. Platform specifications change without notice, so check the current version before you rebuild a workflow around any figure in this post.
Podcast loudness standards, platform by platform
| Platform | Published loudness target | True peak | Where it is published |
|---|---|---|---|
| Apple Podcasts | around -16 dB LKFS, +/- 1 dB | -1 dB FS | audio requirements |
| Spotify playback normalization | -14 LUFS "Normal", -11 "Loud", -19 "Quiet" | below -1 dB TP | loudness normalization, written for music |
| Spotify podcast ads | -16 LUFS, +/- 1.5 LUFS | -2.0 dBTP | podcast ad requirements |
| YouTube | no figure we could find | not stated | not published |
| Buzzsprout Magic Mastering | -16 LUFS stereo, -19 LUFS mono | -1 dB FS | Magic Mastering FAQs |
Apple's page is the anchor. It asks that "the overall loudness remains around -16 dB LKFS, with a +/- 1 dB tolerance" and that "the true-peak value doesn't exceed -1 dB FS", and it names ITU-R BS.1770-5 as the measurement standard. A tolerance of a decibel either way is, in our view, unusually generous for a delivery spec: an episode that lands at -15.2 or -16.8 LUFS is inside it.
Everything else in that table is either a playback behavior, an advertising spec, or a hosting company's house target. None of them contradicts -16.
What loudness normalization actually does to your episode
The important mechanic is that most of these numbers describe playback, not delivery. Spotify measures loudness when you upload and then applies gain when someone presses play: the page states plainly that "we don't process or change your audio tracks before playback". A master that arrives louder than the target is turned down at the listener's device. The file itself is untouched.
That distinction decides how much any of this matters. If you squash an episode with a limiter to make it loud, normalization gives back the level and keeps the damage. The result is a flat episode that still plays at the same level as everyone else's, because the dynamic range you traded away is gone and the loudness you bought with it has been removed.
It also means normalization is not guaranteed. Spotify's page says its web player does not use loudness normalization, and neither do "3rd party devices" such as TVs and speakers. Podnews frames the practical test for a podcaster as not having to touch the volume control when playing several shows in a row - which only holds if your own episodes are consistent with each other, whatever the platform does.
The -14 LUFS figure is a music number that escaped
Search for a podcast loudness target and you will be told that Apple wants -16 LUFS, Spotify wants -14 and YouTube wants -14. The first is published. The second two are not podcast requirements.
Spotify's -14 LUFS comes from its loudness normalization article for artists, which describes how it levels tracks "according to the ITU 1770 standard" and lets Premium listeners pick -11 LUFS (Loud), -14 LUFS (Normal) or -19 LUFS (Quiet). It is about music playback. Spotify's own podcast-facing documentation sets format rules without a loudness figure: its supported file formats page recommends MP3 "with bitrates between 96 and 320 Kbps" and a maximum episode duration of 12 hours, and says nothing about LUFS.
Where Spotify does publish a spoken-word loudness number, it is -16, not -14. Its podcast ad requirements ask for "an integrated average loudness of -16 LUFS (+/- 1.5 LUFS)" with "a True Peak limit of -2.0 dBTP". If Spotify specifies -16 for the audio it sells inside podcasts, in our view there is no case for mastering your episodes to -14 to please it.
As for YouTube, we could find no published loudness target for podcast or video audio as of October 23, 2026. The figures circulating are estimates from audio engineers watching the player's own normalization readout, not a documented requirement. We would not master to an undocumented number.
Auphonic, whose algorithms Buzzsprout licenses for its own mastering feature, argued the same case in a 2019 post on loudness targets: "a loudness target of -16 LUFS for podcasts is fine on Spotify as well", and "never set a loudness target higher than -16 LUFS for spoken word audio". Its reasoning is about dynamics - a higher target squeezes the peak-to-loudness range until speech sounds flat. That post is seven years old and predates Spotify's current page, so treat it as an argument rather than a current spec.
Should you export a podcast in mono or stereo?
This is the one place the number genuinely changes, and it is where most confusion starts.
Integrated loudness sums channels, so the same voice measures differently depending on how many channels carry it. Podnews puts it this way: "Mono audio is essentially taking two stereo tracks and adding them together, so mono audio can sound louder than stereo", and concludes that "a mono file at -19 LUFS should sound just as loud as a stereo file at -16 LUFS".
Hosting companies encode the same pair of numbers. Buzzsprout's Magic Mastering, which "has licensed advanced algorithms from Auphonic", states: "Our targets are -19 LUFS for a mono (single channel) recording and -16 LUFS for a stereo (two-channel) recording", both at a -1 dB FS true peak.
Apple takes the decision out of your hands for lossless uploads. Its audio requirements say "single-channel audio will not be accepted for WAV or FLAC files" and that a mono source should be delivered with identical left and right channels. A dual-mono file is a two-channel file, so it takes the stereo target.
The rule we would follow: if the file you publish has two channels, target -16 LUFS, even when both channels are identical. Target -19 only for a genuinely single-channel file, which in practice means an MP3 you have chosen to encode as mono to halve the bitrate.
What true peak should a podcast be?
Apple's ceiling is -1 dB FS true peak, and that is the number to build into your limiter. Spotify's advice for masters is the same, "below -1 dB TP max", with one extra condition: if the master is louder than -14 LUFS integrated, keep the true peak below -2 dB to avoid added distortion. Its podcast ad spec goes straight to -2.0 dBTP.
The reason for the headroom is encoding. True peak measures the peaks that appear between samples once audio is reconstructed, and lossy encoding to MP3 or AAC can push a file that read exactly 0 dBFS in your editor above full scale on playback. A decibel of headroom absorbs that.
If you master at -16 LUFS, -1 dBTP is enough. If you deliberately run hotter - some news and daily shows do - we would use -2 dBTP, which is what both Spotify documents point to.
LUFS and LKFS are the same measurement
Apple writes LKFS, nearly everyone else writes LUFS, and the two are interchangeable. Podnews states it directly: "LKFS and LUFS relate to the same thing", with LKFS the term the US broadcast industry prefers. Both describe loudness over a period of time, which is why the figure you care about is integrated loudness across the whole episode rather than a momentary or short-term reading.
Two related numbers are not loudness and are often confused with it. Peak normalization sets the highest sample to a value and tells you nothing about perceived level. Compression and limiting change dynamics. A loudness target is neither: it is a measurement you hit by applying gain after the mix is finished.
Bitrate and format: Apple prefers AAC, Spotify's docs name MP3
The loudness target travels with the encode, and here the two biggest platforms do not fully agree.
Apple's requirements for files served from your RSS feed say "we strongly recommend using AAC instead of MP3", and list 128 to 256 kbps at 44.1 or 48 kHz for stereo and 64 to 128 kbps at 44.1 or 48 kHz for mono. Spotify's supported-formats page recommends MP3 at 96 to 320 kbps and, when an episode fails to ingest, tells publishers to point the feed's enclosure tag at "an accepted format" such as MP3.
One file has to satisfy both, because one RSS enclosure serves every app. In our view MP3 at 128 kbps mono or 192 kbps stereo remains the safe default until Spotify's public documentation lists AAC alongside it - you give up a little efficiency and nothing else.
A five-step export pass for every episode
- Finish the mix first. Set levels, de-noise and level between speakers before you measure anything, because loudness normalization is a final gain stage, not a fix for an unbalanced mix.
- Measure integrated loudness across the finished episode with any meter that reports integrated LUFS and true peak, not momentary values.
- Set the target by channel count: -16 LUFS for a two-channel file, -19 LUFS for a true mono file.
- Set the limiter ceiling to -1 dBTP, or -2 dBTP if you are mastering louder than -16 LUFS.
- Encode once, then measure the encoded file. The encode is what listeners hear, and it is where inter-sample peaks appear.
Run the same pass on every episode and, in our view, the consistency problem takes care of itself. What a well-levelled show buys you is not loudness; it is a listener who never reaches for the volume control.
Where the work gets done
Upfynd lists 97 tools in Audio & Podcasting as of October 2026, and the loudness step lands in one of three places in a typical workflow.
- In your editor, as a loudness-normalization stage before export. This is the only option that lets you hear the result before publishing.
- In an automated post-production service such as Auphonic, which applies a loudness target and true-peak limit as a processing step.
- At the host. Buzzsprout offers Magic Mastering, which its FAQ says is "applied to your episodes during the audio uploading process" and "isn't designed to run on your back catalog" - so it levels what you upload from now on, not what is already published. Buzzsprout charges "a small fee" for it, billed at the end of the cycle after use; it publishes no dollar figure on that page, so check the price in your account.
Video changes none of the loudness arithmetic but adds a second set of delivery rules, and the Video & Streaming category covers the tools for that side.
If you make one of these tools, you can submit it for a free listing, and new launches are ranked by upvotes from the people using them.
The next step is small and worth doing today: open your last published episode, measure its integrated loudness and true peak, and compare it with the episode before. If those two numbers differ by more than a decibel, we would look at your export step before your microphone.
Frequently asked questions
What LUFS should a podcast be?
Target -16 LUFS integrated for a two-channel file and -19 LUFS for a true mono file, with a true peak no higher than -1 dBTP. Apple Podcasts publishes around -16 dB LKFS with a plus or minus 1 dB tolerance, and LKFS and LUFS are the same measurement.
Does Spotify normalize podcast loudness?
Spotify measures loudness at upload and applies gain at playback rather than changing your file. Its published -14 LUFS target appears on its loudness normalization page for music tracks. Spotify's podcast ad specification asks for -16 LUFS instead, and its web player does not normalize at all.
Do I need a different master for each podcast platform?
In our view, no. Apple Podcasts is the only major listening platform we could find that publishes a loudness requirement for episodes, and the others adjust level at playback instead of rewriting your audio. One export at -16 LUFS with a -1 dBTP ceiling satisfies Apple and survives every playback normalizer unharmed.
What is the difference between LUFS and LKFS?
Nothing measurable. Podnews states that LKFS and LUFS relate to the same thing, with LKFS the term the US broadcast industry prefers and LUFS used almost everywhere else. Both are loudness measured over time, which is why integrated loudness across the whole episode is the figure that matters.
Should I export a podcast in mono or stereo?
Either works, but the target changes. Integrated loudness sums channels, so a mono file at -19 LUFS sounds about as loud as a stereo file at -16 LUFS. Apple will not accept single-channel WAV or FLAC uploads and asks for identical left and right channels instead.
What true peak should a podcast be?
Use -1 dBTP, which is Apple's published ceiling and matches Spotify's mastering advice. Keep -2 dBTP in reserve for masters louder than -16 LUFS, since lossy MP3 and AAC encoding can lift inter-sample peaks above full scale even when your editor showed none.
Products in this article
About the author
Nihar Rout
CEO & Co-founder