How loud should a podcast be? The two numbers Apple publishes

Minus 16. That is the number Apple publishes, and it is the short answer to the question of how loud a podcast should be: an overall loudness of about -16 dB LKFS, with a tolerance of plus or minus 1 dB, and a true-peak value that never goes above -1 dB FS. Apple's own audio requirements document for Apple Podcasts for Creators states both figures and names the measurement standard they are calculated under, ITU-R BS.1770-5, published by the International Telecommunication Union. Hit those two numbers and your episode plays at the same apparent volume as the professionally mastered shows sitting next to it in a listener's queue.

If your show is not listed on PodAnswer yet, you can add it free, and a listed show gets its own page that can surface when somebody searches the show's name rather than a topic.

Two figures, one of them easy to miss

Apple's audio requirements page gives the loudness target and the peak ceiling as a pair, and shows that fail listener expectations usually got the second one wrong. Loudness is an average over the whole episode. True peak is the single loudest instant, measured with the oversampling that reveals peaks hiding between digital samples. An episode can average a perfect -16 LKFS and still clip on a laugh, a cough or a chair scrape, because the average absorbs a transient that the peak meter does not.

A note on the units, since they trip up almost everybody. LKFS and LUFS are the same scale with different names. Apple writes LKFS, Spotify writes LUFS, your editor probably writes LUFS, and a reading of -16 in one is -16 in the other. Both are negative because the scale runs down from digital full scale, so a louder episode is a smaller number in absolute terms. Minus 14 is louder than minus 16. Minus 23 is considerably quieter than both.

What the meter counts while it listens

ITU-R BS.1770-5 is a measurement recommendation, not a loudness target, and the distinction matters when you read a meter. The standard specifies a frequency weighting, called K-weighting, that approximates how human hearing treats the spectrum, then defines how the weighted signal is averaged over time and how gating removes silence from the calculation. That is why a loudness meter and a peak meter disagree so often. The peak meter reports physics. The loudness meter reports an approximation of perception.

Your editor will usually show three readings. Momentary loudness covers a window of a few hundred milliseconds. Short-term loudness covers roughly three seconds. Integrated loudness covers everything from the start of measurement to the end, and integrated is the one Apple's -16 figure refers to. Checking momentary loudness against a published target produces a number that bounces around and tells you nothing about the file.

Where Spotify's number comes from, and why the gap costs you nothing

Spotify publishes a different figure. Its loudness normalization document, which is written about music uploads, says Spotify adjusts tracks to -14 dB LUFS according to the ITU 1770 standard, measures loudness at upload without altering the file, and applies the correction at playback rather than at ingest. The same document lists the three levels a Premium listener can choose in app settings: Loud at -11 dB LUFS, Normal at -14, and Quiet at -19. On the Loud setting Spotify applies a limiter that engages at -1 dB with a 5 millisecond attack and a 100 millisecond decay to keep soft dynamic material from distorting.

Read those two documents side by side and the two-decibel difference between -16 and -14 stops looking like a decision you need to agonize over. Both platforms adjust playback gain toward their own target. What they cannot fix is an episode that arrives already clipped, or one mastered so far down that lifting it also lifts the room noise, the laptop fan and the air conditioning into audibility. Land anywhere between -16 and -14 integrated with true peak under -1 dB FS and every major player will treat your file kindly. Chasing a single decimal place is wasted effort.

The order of operations most shows get backwards

Apple's document is specific about sequencing, and this is the part worth copying into your workflow notes. The preconditioning steps need to occur before the encoding process. Apple's stated reason is that audio compression algorithms typically do not modify the loudness of a file and might clip the signal if the recommended true-peak value is not respected. Encode first and normalize second, and you are normalizing a file that already has the damage baked in.

So the sequence runs: edit, then set loudness and peak on the finished mix, then encode to the delivery format, then check the encoded file once more before it goes to your host. That last check catches the cases where an encoder nudged a peak over the line.

There is a second mechanism in Apple's document that most hosts never mention. You can embed loudness, dynamic range and peak-level information directly in the file, using the ID3 tags of an MP3 or the header of an MP4. Apple says playback engines can then adjust levels precisely to a target, and that content carrying loudness or Sound Check metadata plays at -16 dB when Sound Check is enabled.

Measuring it without spending anything

You do not need a plugin purchase to see these numbers. ffmpeg's loudnorm filter will measure integrated loudness and true peak on an existing file and print both, which is enough to tell you whether an episode is in range before you publish it. Audacity ships a Loudness Normalization effect that works in LUFS. Adobe Audition, Reaper, Logic and Premiere all expose loudness metering with integrated, short-term and momentary readings. Whichever tool you use, measure the finished mix with music and ads in place, since a cold open at theatrical volume will pull the integrated reading up and leave the conversation underneath it too quiet.

Two readings are worth logging for every episode: integrated loudness and true peak. Keep them in the same spreadsheet where you track your other production numbers and you will spot a drifting microphone gain or a new guest's hot signal within an episode or two rather than after a listener emails you about it.

The complaints that trace back to a level

A show that is too quiet produces one specific complaint. Listeners say they have to turn the car stereo all the way up, and then an ad or the next show in the queue arrives at normal volume and startles them. A show that is too loud produces a different one. Listeners say it sounds harsh, or fatiguing, or that the voices feel pressed flat against each other, which is what happens when heavy compression and amplification remove the dynamic range Apple's document warns about losing.

Remote interviews are where levels fall apart fastest, because two sides of a conversation recorded on different hardware in different rooms rarely arrive matched. Setting each speaker's track to a consistent level before you bounce the mix is part of the same discipline as recording each side locally in the first place. The specifics of that setup are in our guide to recording with a remote guest, and the microphone side of the problem shows up in this answer on capturing a punchy snare sound, which makes the case that capture decisions outrank processing decisions.

Bit rate and channels, since they arrive in the same conversation

Apple's audio requirements document also publishes the delivery specifications, and the loudness question tends to come bundled with them. For RSS feed audio, Apple Podcasts accepts MP3 or AAC, and recommends 64 to 128 kbps for mono and 128 to 256 kbps for stereo at 44.1 or 48 kHz. At the lower sample rates of 22.05 or 24 kHz the recommended ranges drop to 40 to 80 kbps mono and 80 to 160 kbps stereo. Apple strongly recommends AAC over MP3 for feeds, and the MP4 container over ADTS, on the grounds of streaming efficiency and accurate seeking. Subscriber audio uploaded through Apple Podcasts Connect follows a separate specification: WAV, FLAC or MP3, with a floor of 44.1 kHz at 16 or 24 bit, and single-channel WAV and FLAC files rejected outright. The sample-rate side of that specification, including why 48 kHz is now the safer setting for the session itself, is covered in what sample rate to use for a podcast.

None of those settings change your loudness target. They change how much of your mix survives the encode, which is the reason Apple puts the preconditioning instruction in the same document.

A five-minute check before you publish

1. Bounce the finished mix, with music and ads in place, to an uncompressed file.
2. Measure integrated loudness and true peak on that file.
3. Adjust gain so integrated loudness lands between -16 and -14 LUFS, then apply a true-peak limiter at -1 dB FS.
4. Encode to AAC or MP3 at the bit rate your channel count and sample rate call for.
5. Measure the encoded file again, and log both readings next to the episode number.

Common questions

How many decibels should a podcast be? The useful figure is loudness, not a raw decibel level, and Apple publishes it as about -16 dB LKFS with a plus or minus 1 dB tolerance and a true peak no higher than -1 dB FS. A single decibel number taken off a peak meter will not get you there, because peak and loudness measure different things.

What LUFS should a podcast be? Target -16 LUFS integrated if you want to match Apple's published recommendation, or -14 if you prefer to match the figure Spotify publishes for its own normalization. Anywhere in that band is fine, since both platforms adjust gain at playback.

What is a good LUFS level for spoken word? For a dialogue-driven show, integrated loudness between -16 and -14 LUFS with true peak at or below -1 dB FS covers the published guidance from both major platforms. Shows that mix heavy music beds with speech often sit closer to -16 to preserve headroom for the music.

Does loudness affect how my podcast ranks or gets found? No published platform document ties loudness to discovery. Levels affect whether people finish an episode, and completion is a listener-behavior signal rather than a search signal. The search side of getting found comes down to text, which is covered in our podcast SEO guide.

Should every episode be the same loudness? Yes, and that consistency matters more than the exact target you pick. A back catalog that swings by six decibels between episodes trains listeners to reach for the volume control, which is also worth considering if you are repairing older episodes. Our piece on the back catalog covers which old episodes justify the work.

Does episode length change the target? No. Integrated loudness is an average, so a 20-minute episode and a two-hour episode use the same figure. Length has its own tradeoffs, which we went through in how long a podcast episode should be.

Where this leaves you

Set the loudness once, write the two numbers into your export preset, and the question stops coming up. That frees your attention for the part of the show that compounds, which is the text around the audio: titles, show notes, transcripts and question-shaped pages that Google can read.

That is the work PodAnswer does for shows on the network. Growth is $149 a month for four answer articles built from your transcripts, and Network is $349 a month for twelve. The full explanation of how articles get built and published is on the PodAnswer for podcasters page, and the plan details are on the pricing page.