If you need one practical starting point, finish a stereo podcast near −16 LUFS integrated and keep true peak at or below −1 dBTP. For a mono file, −19 LUFS is a common dual-mono convention rather than a universal upload rule. The platform or client specification still wins.
That distinction is the part most loudness charts blur. Apple Podcasts currently recommends overall loudness around −16 dB LKFS with a ±1 dB tolerance and a true-peak value that does not exceed −1 dB FS. Spotify’s public −14 LUFS documentation describes music playback normalization and mastering guidance; it isn't proof that every podcast file must be delivered at −14 LUFS.
Fast decision: use the written delivery brief when one exists. With no brief, −16 LUFS stereo / −1 dBTP is a defensible spoken-word start. Treat −19 LUFS mono as a channel-layout convention you still have to verify, not a magic podcast standard.
Podcast loudness targets at a glance
| Destination or workflow | Integrated loudness | True peak | What the number means |
|---|---|---|---|
| Apple Podcasts recommendation | Around −16 LKFS, ±1 dB | Does not exceed −1 dB FS | Documented preparation guidance for podcast audio |
| Common stereo podcast start | −16 LUFS | At or below −1 dBTP | Widely used convention; confirm the host or client brief |
| Common mono dual-mono convention | −19 LUFS | At or below −1 dBTP | Three LU lower than the stereo convention; playback handling matters |
| PRX recommendation | −16 to −19 LUFS | Follow the production brief | PRX explicitly says there is no single set industry standard |
These aren't four competing truths. Apple publishes a platform recommendation, PRX publishes a working range, and the −16/−19 pair is a production convention built around channel playback. None of them turns a poor mix into a compliant episode merely because the integrated number lands on target.
There is no single enforced podcast loudness standard
Podcast delivery is less uniform than broadcast delivery. A host may publish a recommendation, a network may provide a production sheet, and a player may apply its own optional playback processing. Those are three different things.
Apple’s current page is unusually specific: around −16 dB LKFS, ±1 dB, with the true peak kept under its stated ceiling and measured under ITU-R BS.1770-5. Apple also accepts both mono and stereo MP3 for subscriber audio and RSS distribution. Its page doesn't say that every mono RSS file must be −19 LUFS.
Our streaming loudness comparison says Normal playback adjusts music to −14 LUFS, while Premium listeners can choose Loud at −11 or Quiet at −19. It also says the web player and some third-party devices do not use that normalization. That's useful evidence about Spotify music playback, but it shouldn't be relabelled as a universal podcast-upload requirement.
The practical rule is simple: label each number by its scope. Is it an upload requirement, a production recommendation, a playback reference, or just your own repeatable house target? If the source doesn't say, don't promote the number to a rule.
Why mono is often quoted at −19 LUFS
A true mono file has one measured channel. Many listeners hear that file through two speakers. The common −19 LUFS mono convention applies a 3 LU offset so dual-mono playback lands near the perceived level of a −16 LUFS stereo programme.
The catch is implementation. Auphonic’s technical explanation notes that playback devices do not all apply the expected dual-mono offset consistently. That is why “mono always equals −19” is too confident.
- If the client says −19 LUFS mono, deliver −19 and document the measurement.
- If the host says around −16 LKFS for all podcast audio, do not silently substitute −19.
- If no one specifies a target, choose one convention, test it on the actual player path, and keep every episode consistent.
Duplicating one mono channel into identical left and right channels also changes what the file is. A two-channel dual-mono export is stereo as far as many encoders and meters are concerned, even though the content is the same in both channels. Check the delivered file rather than the session label.
Read Integrated LUFS and true peak together
ITU-R BS.1770-5 defines measurement algorithms for programme loudness and true-peak signal level. It doesn't tell every podcast where to land; it makes measurements comparable.
- Integrated LUFS (I) accumulates the gated loudness of the measured programme. Reset the meter and measure the complete episode or the exact programme region named by the brief.
- True peak (dBTP) estimates peaks in the reconstructed signal, including values between stored samples. It is a ceiling, not an average-loudness target.
- Short-term loudness (S) uses a three-second window in EBU Mode and helps locate passages that jump forward or disappear.
- Momentary loudness (M) uses a 400 ms window. These windows follow the definitions in EBU Tech 3341; momentary loudness reacts quickly enough to diagnose individual phrases.
- Loudness range (LRA) describes gated variation across the programme. There is no universal “good podcast LRA” that replaces listening.
A file can pass integrated loudness and still be hard to follow. One painfully loud intro and several quiet interviews may average to the requested LUFS. The meter reports the programme; it won't edit the conversation for you.
You can measure a local file in the SoundForgePro LUFS Meter; the audio stays on the device. Use it for editorial and delivery pre-checks. If a broadcaster, network or contract requires a certified measurement path, use the specified conforming tool.
Normalization does not fix uneven dialogue
Loudness normalization applies a gain change to move a measured programme toward a target. If an episode measures −20 LUFS and the target is −16, a simple first estimate is +4 dB. The true peak rises by roughly the same amount. If that move would cross the ceiling, constant gain alone cannot satisfy both constraints.
That's when people start normalizing repeatedly and make the file worse. Stop. The real problem is dynamics, not arithmetic.
- Use clip gain or automation to correct isolated speakers and phrases.
- Use compression only as much as needed to narrow uncomfortable level swings.
- Use a true-peak limiter for remaining peaks when the delivery needs it.
- Measure the complete programme again.
- Apply the final loudness move only after the mix behaves consistently.
If you work in Sound Forge, the Peak, RMS and LUFS normalization guide separates a constant gain move from compression and limiting. For the full edit before this stage, use the Sound Forge podcast workflow.
Five steps from finished edit to delivery file
1. Finish the editorial and restoration work
Do not set final loudness while cuts, noise reduction or music balances are still changing. Every material edit invalidates the measurement.
2. Control the internal level differences
Listen to the quietest usable sentence, the loudest sentence, the intro and any inserted ad or music. Fix the distracting differences before chasing an integrated number.
3. Reset and measure the full programme
Include the exact start, silence, credits and tail that will be delivered. Read Integrated LUFS and true peak first; use short-term, momentary and LRA to find the cause of a failure.
4. Encode the actual delivery file
Keep a lossless archive master. Create the MP3 or AAC using the host’s current channel, sample-rate and bitrate requirements. Apple’s current RSS guidance accepts MP3 or AAC and recommends AAC in an MP4 container for efficient streaming and accurate seeking.
5. Reopen, remeasure and listen
Lossy encoding can change reconstructed peak behaviour. Measure the uploaded-format file, then audition the opening, the loudest passage, a quiet dialogue section and the end. The file you send is the file that must pass.
Four loudness mistakes that survive a green meter
Measuring only the loudest minute
That gives a useful short diagnostic rather than the integrated result of a 45-minute episode. Reset and run the complete programme.
Using peak normalization as loudness matching
Two files can share the same sample peak and sound radically different. Peak normalization aligns one sample boundary; it doesn't equalize perceived programme loudness.
Treating playback normalization as an upload gate
A player may turn material down, leave it unchanged, or behave differently by device and listener setting. Playback references aren't automatically delivery specifications.
Checking the WAV but not the MP3 or AAC
The archive master is not what the listener downloads. Reopen the encoded file and verify it after the codec.
Podcast loudness FAQ
What is the standard LUFS for a podcast?
−16 LUFS integrated for stereo is the most useful general starting point, usually paired with a true-peak ceiling around −1 dBTP. It is a convention and, in Apple’s case, close to a documented platform recommendation—not one universally enforced upload rule.
Should a mono podcast be −19 LUFS?
−19 LUFS is a common dual-mono convention because it sits 3 LU below the familiar −16 stereo target. Use it when the host or client asks for it, or when your tested playback workflow expects the offset. Do not override a written −16 specification merely because the file is mono.
Does Spotify require podcasts at −14 LUFS?
Spotify’s current public −14 LUFS page documents music playback normalization and artist mastering guidance. It does not establish a universal −14 LUFS podcast-upload requirement. Follow the podcast host or production brief and label Spotify’s number by its actual scope.
What true peak should a podcast use?
−1 dBTP is a practical common ceiling and aligns closely with Apple’s current podcast guidance. A stricter client specification wins. True peak is a maximum reconstructed peak, not the episode’s average volume.
Can loudness normalization replace compression?
No. Normalization changes overall gain. Compression, clip gain and automation change the relationship between quiet and loud passages. If peaks prevent a constant gain move from reaching the loudness target, fix the dynamics first.
Should I measure before or after exporting?
Both. Measure the lossless master to approve the mix, then reopen and measure the encoded delivery file because MP3 or AAC processing can change peak behaviour.
Last fact-checked September 5, 2026 against Apple Podcasts for Creators, Spotify Support, ITU-R BS.1770-5, EBU Tech 3341, PRX and Auphonic technical guidance.