Industry Standard: 96–128 kbps CBR Mono
If you want the short answer: encode your podcast as MP3, 96–128 kbps, CBR, mono, 44.1 kHz. This is what Apple Podcasts recommends, what Spotify accepts, and what virtually every podcast hosting platform expects.
| Setting | Recommended Value | Why |
|---|---|---|
| Format | MP3 | Universal compatibility across all podcast apps |
| Bitrate | 96–128 kbps | 96 for pure speech; 128 if music segments are present |
| Bitrate mode | CBR (Constant Bitrate) | Reliable seeking, predictable file size |
| Channels | Mono | Speech is mono; halves file size vs stereo |
| Sample rate | 44.1 kHz | CD standard, maximum compatibility |
| Loudness | -16 LUFS | Standard for podcast platforms |
Quick rule: 96 kbps mono for talk-only shows. 128 kbps mono if your podcast has significant music segments (intro/outro jingles, background music). Going higher than 128 kbps for a podcast wastes storage and bandwidth with no audible benefit for speech.
Why CBR, Not VBR?
For music, VBR (Variable Bitrate) is generally preferred because it allocates more bits to complex passages and fewer to silence, improving quality-per-byte. For podcasts, however, CBR is the safer choice for several practical reasons:
- Reliable seeking: CBR files allow podcast players to calculate any time position from the byte offset. VBR requires a separate seek table (Xing/VBRI header), and some older podcast apps don't handle it correctly — leading to inaccurate time displays or seeking to the wrong position.
- Accurate duration estimation: RSS feeds include a file size (enclosure length). With CBR, apps can estimate episode duration from the file size alone. VBR makes this impossible without parsing the file header.
- Predictable file sizes: with CBR, you can calculate exact file sizes before encoding. At 96 kbps, every minute costs exactly 720 KB. This makes storage planning for your hosting account straightforward.
- Streaming reliability: CBR streams at a constant rate, which is easier for buffering algorithms in podcast apps to handle, especially on slow cellular connections.
The quality advantage of VBR over CBR is minimal for speech content. Speech is far less complex than music, so VBR would mostly save bits during silence — where quality doesn't matter anyway. The practical benefits of CBR outweigh the marginal efficiency gain of VBR for podcasts.
Why Mono for Podcasts?
A podcast with a single narrator is inherently mono audio. The voice comes from one source and carries no meaningful stereo information. Encoding it as stereo doubles the file size for zero audible benefit.
- 50% smaller files: a 1-hour episode at 96 kbps mono is ~42 MB. The same episode at 96 kbps stereo would be ~42 MB but with the bitrate split between two identical channels, reducing quality per channel.
- Apple's recommendation: Apple Podcasts explicitly recommends mono for spoken-word podcasts in their podcaster guidelines.
- Better quality per bit: at the same bitrate, mono allocates all bits to one channel. At 96 kbps mono, each second gets 96 kbits of data. At 96 kbps stereo, each channel gets only ~48 kbits. The mono version sounds noticeably better.
- Universal playback: mono audio plays from both speakers/earbuds identically. Listeners hear the same thing whether using one earbud or two.
Interview shows: even two-person interviews are typically distributed in mono. While you could pan host and guest to left and right channels, this creates an unpleasant experience for listeners using only one earbud. Most professional podcasters mix all voices to center and export in mono.
Sample Rate: Stick with 44.1 kHz
For podcast distribution, 44.1 kHz is the correct sample rate. Here's why:
- CD standard: 44.1 kHz has been the digital audio standard since 1982. Every device, app, and platform supports it without resampling.
- Exceeds speech needs: human speech ranges from about 85 Hz to 8 kHz (with sibilance extending to ~12 kHz). 44.1 kHz captures frequencies up to 22.05 kHz — well beyond anything in speech.
- Maximum compatibility: some older MP3 decoders and embedded systems may not handle 48 kHz MP3 files correctly. 44.1 kHz works everywhere.
- No benefit to going higher: 48 kHz, 96 kHz, or higher sample rates capture ultrasonic frequencies that don't exist in speech and aren't preserved by MP3 encoding anyway.
If your recording software captures at 48 kHz (common for video-centric DAWs), the conversion to 44.1 kHz during MP3 encoding is automatic and lossless for speech content. Modern encoders handle this resampling transparently.
File Size Planning for Podcast Hosts
Podcast hosting plans are often storage-limited (e.g., Libsyn's plans are based on monthly upload allowance). Knowing your file sizes in advance helps you choose the right plan and avoid overages.
| Duration | 96 kbps Mono | 128 kbps Mono | 128 kbps Stereo | 192 kbps Stereo |
|---|---|---|---|---|
| 15 min | 10.5 MB | 14 MB | 14 MB | 21 MB |
| 30 min | 21 MB | 28 MB | 28 MB | 42 MB |
| 1 hour | 42 MB | 56 MB | 56 MB | 84 MB |
| 2 hours | 84 MB | 112 MB | 112 MB | 168 MB |
For a weekly show publishing 4 one-hour episodes per month:
- 96 kbps mono: ~168 MB/month — fits Libsyn's basic plan (250 MB)
- 128 kbps mono: ~224 MB/month — tight fit on 250 MB plan
- 192 kbps stereo: ~336 MB/month — needs a larger plan
Quick formula: file size (MB) = bitrate (kbps) × duration (seconds) ÷ 8,000. For example, 96 kbps × 3,600 seconds ÷ 8,000 = 43.2 MB for a 1-hour episode.
ID3 Tags for Podcasts
ID3 tags are metadata embedded in the MP3 file. Podcast apps read these tags to display episode information. Properly tagged files look professional and help listeners navigate your content.
- Title (TIT2): the episode title. Keep it concise — long titles get truncated in podcast app UIs.
- Artist (TPE1): your podcast/show name.
- Album (TALB): your podcast/show name (same as artist for most podcasts).
- Track number (TRCK): episode number (helps ordering in some apps).
- Genre (TCON): set to "Podcast".
- Year (TDRC): publication year.
- Cover art (APIC): episode or show artwork. Keep it under 500 KB — large cover images bloat every episode file. Use JPEG at 1400×1400 or 3000×3000 pixels compressed to quality 70–80.
While RSS feeds also carry this metadata, embedded ID3 tags ensure the information stays with the file even when downloaded separately or shared outside a podcast app.
Normalization for Consistent Volume
Loudness normalization ensures your podcast plays at a consistent volume — no sudden jumps or drops that force listeners to reach for the volume control.
The podcast industry has settled on -16 LUFS (Loudness Units Full Scale) as the target:
- -16 LUFS: the standard for most podcast platforms. Loud enough to be clear in noisy environments, quiet enough to avoid distortion.
- -14 LUFS: used by Spotify for music. Some podcasters target this for slightly louder playback, but it leaves less headroom.
- True peak limit: keep peaks at or below -1 dBTP (decibels True Peak). This prevents clipping artifacts from inter-sample peaks during MP3 encoding and DAC reconstruction.
| Platform | Target Loudness | True Peak Limit |
|---|---|---|
| Apple Podcasts | -16 LUFS | -1 dBTP |
| Spotify | -14 LUFS (music) / -16 LUFS (speech) | -1 dBTP |
| YouTube | -14 LUFS | -1 dBTP |
| EBU R128 (broadcast) | -23 LUFS | -1 dBTP |
Apply loudness normalization before MP3 encoding, during your editing/mastering stage. Normalizing after encoding can introduce additional quality loss. Most podcast editing software (Audacity, Hindenburg, Adobe Audition, Descript) includes loudness normalization as a standard feature.
Consistency matters more than the exact number. A podcast that's consistently -18 LUFS sounds better to listeners than one that swings between -12 and -22 LUFS from episode to episode. Pick a target and stick to it across all episodes.