Here is a complaint nobody writes in a review but everybody acts on. A listener in the rain at a bus stop, earbuds in, thumb on the volume. Your episode comes on quieter than the one before it, so they turn it up. Your guest speaks, quieter still, so they turn it up again. An ad hits at full production loudness and they yank it down. By the time your best story arrives, they have adjusted the volume four times and formed an opinion about your show that has nothing to do with the story.
Levels are the part of podcasting that listeners physically interact with, which makes them the most noticed technical fault after noise, and the one with the most confusing vocabulary. This guide takes the three complaints people actually have, explains what the numbers mean without an engineering degree, shows what the big platforms do to your file when it plays (from their own documentation), and untangles the four tools people use interchangeably. At the end there is an order of operations that never has to be done twice.
Three Different Complaints, Three Different Causes
"Too quiet" is usually the whole episode landing well below the loudness other shows are delivered at. A raw home recording often sits at -24 LUFS or lower; the shows around it in the listener's queue sit at -16 to -14. The listener does not know the numbers, they just know yours needs turning up. The fix is the easiest on this page: measure the finished file and normalise it to the target, once, at the end.
"All over the place" is two voices at two levels, the host close to a good mic and a guest on laptop earbuds, commonly 12 to 14 decibels apart in the raw tracks. Normalising the whole episode does nothing for this, because it moves both voices together; the guest stays 12 decibels under. The fix is to match the voices to each other first, on their own tracks, and only then set the episode's loudness. The guest-level guide walks through it step by step.
"Too loud" is the odd one, because it never sounds too loud to the person who made it. It sounds punchy in the headphones at -12 LUFS with the peaks kissing zero. Then every platform turns it down to its target, the limiter that got it there has already flattened the consonants, and it lands in the queue duller and smaller than a show that was simply delivered at -16. Louder is not safer. Past the target it is only worse.
What the Numbers Mean
Three numbers do all the work, and they measure different things. The first is peak level, in dBFS, decibels relative to full scale: how close the single loudest instant of the file came to the top. Zero is the ceiling; go past it and the sound clips. True peak is the same idea measured more carefully, catching the tiny overshoots that appear when a file is converted to MP3 or AAC, which is why the platforms ask for a ceiling of -1 dBTP rather than 0.
The second is loudness, in LUFS (loudness units relative to full scale; Apple writes LKFS, which is the same thing). Where peak measures the loudest instant, LUFS measures how loud the whole thing feels, averaged over the file and weighted the way human hearing works, under an international standard called ITU-R BS.1770. This is the number the platforms care about, because it is the number ears care about. Two files with identical peaks can differ by 10 LUFS in how loud they sound, which is why "my peaks are fine" and "my show is too quiet" are both true at once for a lot of people.
The third is the scale itself. Decibels are logarithmic and nobody's intuition about them is right, so here is the cheat sheet: 1 decibel is a change nobody notices; 3 is noticeable if you listen for it; 6 is clearly quieter; 10 is roughly half as loud, the psychoacoustic rule of thumb, and the point where a hand reaches for the volume. The typical raw gap between a host and a remote guest, 12 to 14 decibels, is past that line, which is why "I can never hear the guests" is the most common technical complaint in podcast reviews.
How do you read your own file? Any modern editor has a loudness meter that reports integrated LUFS and true peak for a whole file; the free measurement tools do the same from a drag and drop; and a loudness normaliser worth using tells you the reading before and after it works. The number to look at is always the integrated one, measured over the entire episode, not the short-term meter bouncing on the screen while it plays. Write down three readings and you know everything: the host track, the guest track, and the finished mix. If the first two are more than a couple of decibels apart, the episode is "all over the place"; if the third is below -18, it is "too quiet"; if it is above -13, it is "too loud" and about to be turned down.
What the Platforms Do to Your File
This is the part most guides get wrong, so here it is from the platforms' own pages. Apple Podcasts recommends that your file itself be delivered at around -16 LKFS with a tolerance of one decibel and a true peak no higher than -1 dBFS; that is a spec for the file you upload. Spotify works differently: its published loudness page says it measures every file at upload and adjusts playback to -14 LUFS, turning louder files down and quieter files up (with one decibel of headroom kept for the lossy encoding), and it applies that at playback rather than changing your file. Listeners can also pick a Loud, Normal or Quiet setting, at -11, -14 and -19 LUFS respectively, so the same file plays at three different levels depending on the phone it lands on.
YouTube publishes encoding recommendations (AAC-LC, 48 kHz, 128 kbps for mono and 384 for stereo) but no loudness target at all. What producers measure in practice is that loud uploads get turned down to roughly -14 LUFS; you can see the adjustment in the player's "stats for nerds" panel, which shows content loudness and how much it was reduced. The practical reading of all three: deliver at -16 with peaks under -1 and you are inside Apple's spec, two decibels under Spotify's target (which it will quietly raise), and under YouTube's line. Deliver at -12 and all three turn you down, having gained nothing.
Why there are two numbers, not one
Apple's -16 is a recommendation for the file. Spotify's -14 is what it normalises playback to. A file at -16 satisfies Apple as delivered and is raised two decibels on Spotify. A file at -14 is raised nowhere, turned down nowhere, and sits one decibel outside Apple's stated tolerance. Both work; -16 is the safer single number, and if Spotify is your main home, -14 is fine too.
Four Tools, Four Jobs
People say "normalise" when they mean "compress" and "compress" when they mean "limit", and the confusion costs real sound quality, because three of the four change the audio in ways that cannot be undone. Here is what each one actually does.
- Gain turns the whole thing up or down. Nothing else changes. It is how you match a quiet guest to a loud host, and you can use as much of it as you like as long as nothing clips.
- Normalise is gain set for you, to hit a target. Peak normalisation lines up the loudest instant; loudness normalisation, which is the one you want, lines up the LUFS. Done once, at the end, on the finished mix.
- Compress turns the loud moments down so the quiet ones can be brought up, which evens out a voice that swings between a whisper and a laugh. It changes the feel of the voice, and too much of it is the pumping, phone-line sound of over-processed guests. A few decibels of reduction is plenty for speech.
- Limit is a hard ceiling on the peaks: nothing gets past it, so nothing can clip. It is insurance for the -1 dBTP requirement, not a way to make things louder, and if it is working hard on every word the levels before it were wrong.
The Order That Never Needs Redoing
Levels are the last step of an episode, not the first, because everything you do before them moves them. Clean the noise out and the floor drops; quieten the breaths and the gaps change; cut a tangent and the average shifts. Set loudness before any of that and you set it again after. This is the order that only has to happen once:
- Record at a sane gain. Speech peaking around -12 dB on the input meter, the loudest laugh never touching zero. Everything downstream is easier if this is right, and nothing downstream can fix it if it is not.
- Take the room out, one voice per track. Noise removal first, with the floor measured before and after, because any gain you add later raises the room with the voice.
- Clean the takes. False starts, dead air, breaths quietened with the pauses kept, on each track.
- Match the voices with gain. Measure each track's integrated LUFS; move the quieter one up until both are within about 2 LU. A touch of compression only if a voice still swings.
- Mix, then normalise the finished episode. -16 LUFS integrated, true peak no higher than -1 dBTP, in a single pass. Then stop touching it.
- Check the file, not the meters. Measure the export. If it reads -16 and peaks under -1, it will play at the same level as every other show in the listener's queue on every platform.
↗ Try the tool
Loudness Normalizer
Loudness Normalizer has a preset for each target on this page (Apple Podcasts, Spotify, YouTube, mono podcast, broadcast) and runs a true two-pass measurement, so the file you download reads what the preset promised, including the -1 dBTP ceiling. Drop the file, pick the platform, done.
Open Loudness Normalizer →Frequently Asked Questions
Why is my podcast quieter than everyone else's on Spotify?
Either the file is well below -14 LUFS and Spotify could not raise it all the way without the peaks clipping (it keeps one decibel of headroom for the encoding), or the listener has the Quiet setting on, which plays everything at -19. Deliver at -16 with peaks under -1 and the first cause disappears; the second is the listener's choice and affects every show equally.
Should a talk podcast be mono or stereo?
Mono, almost always. Two voices do not need a left and a right, a mono file is half the size at the same quality, and it plays identically on a phone speaker, which is where a lot of listening happens. Stereo is for music beds and produced shows. Whichever you choose, the loudness target is the same.
Can I just put a limiter on the whole episode and call it done?
A limiter stops clipping; it does not set loudness, and it does not match a quiet guest to a loud host. Used as the only tool it flattens the loudest words and leaves the quiet ones quiet. Gain to match, normalise to the target, and let the limiter sit there doing almost nothing, which is what a limiter is for.
Does any of this change if my podcast is on YouTube?
Only the container: YouTube wants AAC audio inside an MP4 at 48 kHz. Deliver the same -16 LUFS, -1 dBTP mix and it lands under YouTube's measured line without being turned down. Loud uploads get reduced; quiet ones are not reliably raised, so err toward the target rather than under it.
Sources and Further Reading
- Apple, Audio requirements for Apple Podcasts: the -16 LKFS recommendation with one-decibel tolerance, the -1 dB true-peak ceiling, and the reference to ITU-R BS.1770.
- Spotify, Loudness normalization: the -14 LUFS playback target, the Loud/Normal/Quiet settings at -11/-14/-19, the one-decibel headroom for quieter files and the -1 dBTP recommendation.
- YouTube Help, Recommended upload encoding settings: AAC-LC, 48 kHz, 128 kbps mono and 384 kbps stereo. YouTube publishes no loudness target; the roughly -14 LUFS figure is what producers measure via the player's stats panel.
- ITU-R BS.1770, the standard for measuring programme loudness (LUFS/LKFS and true peak), and EBU R 128, the broadcast recommendation at -23 LUFS.
- The loudness ladder uses the standard psychoacoustic rule of thumb that 10 dB is roughly a doubling of perceived loudness.
- VoiceEditSuite, Podcast Loudness Standards and Your Guest Is Quieter Than You: the companion guides.
Corrections
Platform figures are quoted from the pages linked above as of September 2026; platforms change their targets and their documentation without notice. Spot an error or a newer number? Tell us through the contact page and we will correct it with a note.
