Learn
Measure your episode's loudness (LUFS), compare it to the −16 LUFS / −1 dBTP target, and normalise it — without leaving the WordPress editor. Step by step, plus the manual route and the mistakes that quietly ruin a file.
To check and fix podcast loudness in WordPress: measure the episode’s integrated loudness (LUFS), compare it to the −16 LUFS / −1 dBTP target, normalise it if it is out of range, and re-check. AudioLinter does all four steps inside the post editor; you can also do it manually in an audio editor and re-import the file.
Master once and let the platforms adjust. Every major service normalises playback, so the useful question is not “how loud can I go” but “what survives normalisation intact”.
Mastering louder than −14 LUFS buys nothing: the platform turns it back down and you keep the squashed dynamics. Per-platform detail lives in Spotify, Apple and YouTube loudness targets.
The repair preserves the input format: a 44.1 kHz file stays 44.1 kHz, and a lossless master comes back lossless rather than transcoded to MP3.
Nothing here requires a plugin. The trade is control against repeatability: you leave WordPress, and every episode depends on someone remembering the same steps.
Use Effect → Volume and Compression → Loudness Normalization, set to −16 LUFS perceived loudness. Do not use “Normalize” or “Amplify” for this — those work on sample peak and say nothing about how loud the episode is perceived to be. Our Audacity loudness guide walks through it with screenshots.
Measure first, then correct, then verify. A single pass that both measures and normalises can silently fall back to dynamic compression when the required gain would breach the peak ceiling, which changes the character of the audio rather than just its level.
# 1. Measure: read "input_i" (LUFS) and "input_tp" (true peak)
ffmpeg -i episode.wav -af loudnorm=I=-16:TP=-1:print_format=summary -f null -
# 2. Verify afterwards, the same way
ffmpeg -i episode-fixed.wav -af ebur128=peak=true -f null -Whatever you use, re-measure the finished file. A correction that was not verified is a guess.
Keeping the check where you publish turns loudness into a repeatable editorial gate: every episode is verified against the same target before it goes live, instead of relying on someone remembering to run a separate tool. That consistency is what makes a back catalogue sound even from episode to episode.
It also puts the result next to the post rather than in someone’s downloads folder. When an episode is questioned three months later, the measurement is still attached to the thing that was published.
Use a tool that measures integrated loudness (LUFS) and true peak inside the editor. AudioLinter adds this to the post editor: upload or pick your audio, run an analysis, and it reports LUFS and dBTP against the −16 LUFS / −1 dBTP podcast target.
Yes. On a paid AudioLinter plan, a one-click repair normalises the file toward −16 LUFS / −1 dBTP, re-analyses it, and lets you download or insert the corrected audio into the post — all inside the editor.
Not for loudness. Normalisation can be done in the editor. You only need an audio editor like Audacity for edits AudioLinter does not perform automatically, such as trimming dead air.
AudioLinter is one. Loudness meters are usually DAW plugins (VST/AU) or browser tools, which means leaving WordPress and re-importing the file. A plugin that measures inside the post editor keeps the check attached to the thing you actually publish.
Master once at −16 LUFS integrated with a true peak at or below −1 dBTP. Spotify and YouTube normalise to about −14 LUFS and will turn a −16 LUFS episode up slightly; Apple Podcasts targets −16 LUFS. Mastering louder than −14 LUFS gains nothing, because the platforms turn it back down — and you keep the reduced dynamic range.
Because peak normalisation and loudness normalisation are different operations, and because lossy encoding regrows peaks. Normalising to −1 dBFS sample peak still leaves inter-sample peaks that a decoder reconstructs above 0 dBFS. Measure true peak (dBTP), not sample peak, and leave headroom before encoding to MP3 or AAC.
No. The verification analysis that runs automatically after a repair is free — you cannot switch it off, so charging for it would be unfair. Only analyses you start yourself count against the daily quota.
The −16 LUFS target is defined for stereo. A mono file played at the same measured loudness is often quoted as −19 LUFS, because some platforms sum mono to both channels and gain 3 LU in the process. If you publish mono, check what your host does rather than assuming.