Podcast Audio Standards 2026: What Apple, Spotify and YouTube Actually Require

Ask three podcasters what loudness to export at and you will get four numbers, at least one of them wrong and all of them delivered with confidence. It is not their fault. Apple writes its spec in LKFS, Spotify writes its in LUFS on a page addressed to musicians, and YouTube does not publish a loudness figure at all. The advice industry fills the gaps with numbers that have drifted a long way from the source documents.

This is a reference piece. Every figure in it comes from the platform's own documentation as of September 2026, linked in the sources at the end, and where a platform says nothing we say that rather than guessing. It covers loudness, true peak, format, sample rate and bitrate for Apple Podcasts, Spotify and YouTube; explains what each platform does to your file when it plays; and ends with the one export that passes everywhere, so you can set it once and stop thinking about it.

Where the Numbers Come From

All three platforms measure loudness the same way, under an international standard called ITU-R BS.1770. It defines LUFS, loudness units relative to full scale, as an average of how loud a whole programme feels, weighted for human hearing rather than for a meter, and it defines true peak, which catches the small overshoots that appear when audio is converted to MP3 or AAC. Apple's page cites the standard by name (revision BS.1770-5) and uses the term LKFS; Spotify's page cites "the ITU 1770 standard" and says LUFS. They are the same unit. Broadcast television standardised on -23 LUFS under the European EBU R 128 recommendation in 2010; streaming platforms, playing to earbuds in noisy places, settled higher, in the -16 to -14 range, which is why podcast targets sit where they do.

The other half of every spec is the file itself: what codec, at what sample rate, at what bitrate. Here the platforms differ more, because Apple serves the file you give it, Spotify transcodes what it serves to listeners, and YouTube re-encodes everything on upload. Those differences explain most of the apparently contradictory advice, and they are set out per platform below.

Apple Podcasts

Apple's audio requirements page is the most complete of the three and the one to design around. For episodes delivered by RSS feed, it accepts MP3 or AAC, and it says plainly that it "strongly recommend[s] using AAC instead of MP3", delivered in an MP4 container rather than the older ADTS wrapper. It publishes a bitrate table by channel count and sample rate: for mono at 44.1 or 48 kHz, 64 to 128 kbps; for stereo at the same rates, 128 to 256 kbps; and lower ranges (40 to 80 mono, 80 to 160 stereo) at 22.05 or 24 kHz for voice-only shows that want small files. It notes that smaller bitrates "may include audible artifacts" and larger ones cost bandwidth, which is the honest trade-off.

On loudness, Apple recommends 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." Two things about that sentence matter. It is a recommendation for the file you deliver, not a description of what the app does at playback; and the tolerance is one decibel either side, so -17 and -15 are inside it and -14 is not. If you deliver one file to every platform, this is the spec to hit, for reasons that become clear when you read Spotify's.

Spotify

Spotify's published loudness page is written for music but describes the behaviour of the whole app. It says the platform "adjusts tracks to -14 dB LUFS, according to the ITU 1770 standard", that "negative gain is applied to louder masters" to bring them down and "positive gain is applied to softer masters" to bring them up, and that this is "applied during playback": Spotify measures at upload and does not process or change the file itself. For quieter files it keeps one decibel of headroom for the lossy encoding, which means a very quiet file with high peaks cannot be raised all the way. It recommends keeping true peak below -1 dBTP, or below -2 if the file is louder than -14.

The detail most guides miss is that listeners choose the target. The app offers three volume settings, Loud at -11 LUFS, Normal at -14 and Quiet at -19, so the same episode plays at three different levels on three different phones. That is one reason chasing a precise Spotify number is pointless: whatever you deliver between -16 and -14 is moved to the listener's setting anyway, and the only thing that survives the trip is whether the file was clean, uncompressed to death, and under the peak ceiling. For podcasts specifically, MP3 remains the standard delivery format through RSS, and Spotify transcodes what it streams to listeners at bitrates that depend on their subscription and settings.

YouTube

YouTube publishes encoding recommendations for uploads and nothing about loudness. The recommended settings page asks for an MP4 container, AAC-LC audio (Opus is also accepted), a 48 kHz sample rate, and audio bitrates of 128 kbps for mono, 384 kbps for stereo and 512 kbps for 5.1. That is the whole published audio spec. Because YouTube re-encodes everything on upload, what you deliver is a source for their encoder rather than the file listeners hear, which is why the recommended bitrates are generous: a better source gives the encoder more to work with.

On loudness, the honest statement is that YouTube does not publish a target, and what producers measure is that loud uploads are turned down to roughly -14 LUFS. The player's "stats for nerds" panel shows a "content loudness" figure and the reduction applied, which is how the industry arrived at the number. Quiet uploads are not reliably raised. So the practical rule for a video podcast is the same as for audio: deliver around -16 to -14, peaks under -1, and you land under the line without being touched; deliver hot and you are turned down after your own limiter has done its damage.

Mono, Stereo and the File-Size Question

The bitrate tables look like a lot of choices and they collapse to two. A spoken-word show should be mono: two voices do not need a left and a right, mono halves the file at the same quality per channel, and it plays identically on a phone speaker, which is where a large share of listening happens. Apple's own table puts mono at 64 to 128 kbps and YouTube's at 128; a mono MP3 or AAC at 96 to 128 kbps is inside every recommendation. Stereo is for shows with music beds, sound design or produced segments, and Apple's 128 to 256 kbps range covers it; YouTube's 384 is a source-quality figure for their encoder, not what listeners receive.

The arithmetic is worth having in your head. Bitrate in kilobits per second, divided by eight, is kilobytes per second; times 3,600 is an hour. So an hour at 96 kbps is about 43 megabytes, at 128 kbps about 58, and a stereo file at 256 kbps about 115. The listener on a data plan notices the difference between 43 and 115 megabytes an episode; their ears, on earbuds at a bus stop, almost never notice the difference between 96 and 256 kbps on speech. Spend the bits where they show.

One File That Passes Everywhere

Put the three specs on top of each other and the overlap is not small; it is most of the page. This is the export that sits inside all three, and it is the only one you need:

• Loudness: -16 LUFS integrated. Inside Apple's -16 plus or minus 1. Two decibels under Spotify's -14, which Spotify raises at playback with headroom to spare. Under YouTube's measured line, so nothing is turned down.
• True peak: -1 dBTP or lower. Apple's ceiling, Spotify's recommendation, and safe for YouTube's re-encode.
• Channels: mono for talk, stereo only if there is music or sound design that needs it.
• Sample rate: 48 kHz. Accepted by Apple and Spotify, required by YouTube, and the rate your interface probably recorded at anyway; 44.1 is fine for audio-only feeds.
• Format and bitrate: AAC or MP3, 128 kbps mono (or 96 for a very small file), 192 to 256 stereo. AAC in MP4 if you are following Apple's recommendation, MP3 if your host or workflow expects it; both are accepted everywhere.
• For YouTube: the same audio inside an MP4 with your video or static image, AAC-LC, 48 kHz. The loudness does not change.

What Normalisation Does and Does Not Fix

Because Spotify and YouTube normalise at playback, a reasonable person asks why any of this matters: if they move the file to their target anyway, why not upload whatever? Three reasons, and they are the ones that separate shows that sound produced from shows that sound uploaded. First, normalisation moves the whole file together. If your guest is 12 decibels under you in the file, they are 12 decibels under after normalisation; the platform cannot fix a balance problem, only a level one. Second, normalisation can turn down freely but can only turn up as far as the peaks allow, so a quiet file with high peaks stays quiet, and a quiet file that was limited hard to raise it arrives sounding squashed. Third, Apple does not normalise at playback in the way Spotify describes; it asks you to deliver at the target, and if you do not, that is how it plays.

So the work is still yours, and it is small: voices matched to each other, noise taken out before levels are set, breaths handled without shrinking the pauses, and one loudness pass at the end that measures the finished file. The platforms then have nothing to do, which is the goal. The full workflow, in the order that never needs repeating, is in Levels Explained, and every step of it for an episode is on the For Podcasters page.

Frequently Asked Questions

Is LKFS different from LUFS?

No. LKFS is the name used in the ITU standard and by Apple; LUFS is the name used by the EBU and by most software. Same measurement, same numbers. -16 LKFS is -16 LUFS.

Everyone says -14 LUFS for podcasts. Is -16 wrong?

-14 is Spotify's playback target, and it is a fine number for a file if Spotify is your main home. -16 is Apple's stated recommendation for the file, and Spotify raises a -16 file to -14 at playback anyway. Either works; -16 is the single number that is inside every published spec, which is why it is the one we recommend for a file that goes everywhere.

Should I switch from MP3 to AAC because Apple recommends it?

AAC is a better codec at the same bitrate and Apple prefers it, but MP3 remains the format the podcast ecosystem was built on, and every host, app and platform accepts it. If your workflow is MP3 and it is not causing problems, it is not a problem. If you are setting up fresh, AAC in an MP4 is the forward-looking choice.

44.1 or 48 kHz?

Both are accepted by Apple and Spotify; YouTube asks for 48. Use whatever your recording was made at and avoid converting between them for no reason. If you publish to YouTube as well as audio feeds, 48 throughout is the simplest choice.

Sources and Further Reading

• Apple, Audio requirements for Apple Podcasts: accepted formats, the AAC-over-MP3 recommendation, the bitrate table by channel and sample rate, the -16 dB LKFS recommendation with one-decibel tolerance, the -1 dB FS true-peak ceiling, and the reference to ITU-R BS.1770-5.
• Spotify, Loudness normalization: the -14 dB LUFS playback target under ITU 1770, positive and negative gain at playback, the one-decibel headroom for quieter files, the Loud/Normal/Quiet settings at -11/-14/-19, and the -1 dBTP (or -2 dBTP) recommendation.
• YouTube Help, Recommended upload encoding settings: MP4 container, AAC-LC or Opus, 48 kHz, and audio bitrates of 128 kbps mono, 384 kbps stereo and 512 kbps 5.1. The page publishes no loudness target; the roughly -14 LUFS figure is what producers measure via the player's stats panel.
• ITU-R BS.1770, Algorithms to measure audio programme loudness and true-peak audio level, and EBU R 128, the European broadcast loudness recommendation at -23 LUFS.
• VoiceEditSuite, Podcast Loudness Standards and Levels Explained: the companion guides.