CutFast CutFast
Guides

The Podcaster's Guide to Audio-Only HLS in 2026 (Apple Podcasts Ready)

Published · By CutFast Team
Add CutFast as a preferred source on Google See more CutFast in Top Stories and AI answers.

If you’ve been running a podcast through Anchor, Buzzsprout, or Transistor and are starting to wonder why you pay $20/month to host a few MP3 files, 2026 is the year to look seriously at self-hosted HLS. Apple’s video podcast push has dragged the rest of the ecosystem along with it, and audio-only HLS is now a first-class citizen — not a hack. The good news: you don’t need ffmpeg, you don’t need a build server, and you don’t need to learn what a “transport stream” is. You need a browser, an MP3, and about ten minutes.

This is the practical walkthrough. We’ll skip the marketing and get to the bytes.

Why audio-only HLS matters in 2026

Two things changed. First, Apple Podcasts Connect now strongly prefers HLS for any podcast that wants to enable video, transcripts-with-timing, or chapter art beyond the basics — and that pressure has trickled into audio-only requirements as platforms unify their pipelines. Second, the playback experience is genuinely better: HLS clients fetch byte ranges of small segments instead of streaming a whole 80MB MP3, so a listener tapping around your episode jumps to the right second instead of buffering for ten. On flaky cellular, the client can pause and resume mid-segment without losing position. None of that is possible with a single progressive MP3.

There’s also a quieter benefit. Most podcast CDNs charge per GB egress. HLS lets the client stop downloading the moment a listener stops listening — which, if your average listener bails at 70%, is a 30% bandwidth saving you’d otherwise pay for.

MP3 vs AAC segments — pick once, stick with it

HLS doesn’t define one audio container. You have three reasonable choices for audio-only output, and Mediabunny (the engine behind audio-to-hls) supports all three. The decision matters because re-encoding later means a new master playlist URL and broken episode caches.

Segment formatFile extensionBitrate sweet spotBest forApple Podcasts
MP3.mp396–192 kbpsMaximum compatibility, older devices, simple workflowsSupported
AAC (ADTS).aac64–128 kbpsSmaller files at same perceived quality, modern appsPreferred
WAV.wavLosslessArchival, niche audiophile feedsSupported but huge

For 99% of podcasters the answer is AAC at 96 kbps. You get roughly 30% smaller files than MP3 at indistinguishable quality for spoken word, and Apple’s own documentation lists AAC-LC as the recommended codec. Use aac-to-hls if your source is already AAC; use mp3-to-hls if you’re converting from an MP3 master and don’t want to re-encode (Mediabunny will keep your MP3 segments as-is, which is faster and lossless relative to your source).

Pick WAV only if you’re hosting a music or field-recording podcast where bandwidth doesn’t matter.

Browser-based packaging — the actual walkthrough

Open audio-to-hls in any Chromium or Safari browser. The page runs entirely client-side via WebCodecs and Mediabunny — your audio file never leaves your machine. There’s no upload, no queue, no “your file is being processed.”

  1. Drop your MP3 (or AAC, WAV) onto the page. Files up to a few hundred MB work fine; the limit is your browser’s memory, not a server quota.
  2. Pick segment format. Default is AAC-ADTS. Change to MP3 if you want zero re-encoding from an MP3 source.
  3. Set segment duration. 6 seconds is the sweet spot — Apple’s HLS authoring guidelines recommend 6s targets, and shorter segments mean faster seeks but more HTTP requests.
  4. Hit package. The tool produces a zip containing master.m3u8, audio.m3u8, and your numbered segment files (audio0.aac, audio1.aac, …).
  5. Unzip locally. You now have a folder you can upload anywhere that serves static files.

That’s it. There’s no encoding queue because there’s no server — your CPU did the work, and your CPU is faster than a shared transcoder anyway.

One honest limitation: Mediabunny’s HLS output is single-rendition. You get one bitrate, not an adaptive ladder. For audio-only podcasts this is almost never a problem (the difference between 64 and 128 kbps is barely worth switching for), but if you specifically need multi-bitrate adaptive audio, you’ll need ffmpeg. Same goes for embedded chapter markers — the M4A chap atom isn’t muxed; chapters live in your RSS feed instead, which is where most podcast clients read them anyway.

Hosting and serving — the part that actually costs nothing

This is where self-hosting wins. A 30-minute weekly podcast at 96kbps AAC is roughly 22MB per episode. Cloudflare R2 charges $0.015 per GB stored and zero egress. Even a 10,000-listener show costs you a few dollars a month, all-in.

Recommended setup: Cloudflare R2 + Worker.

Upload your unzipped HLS folder to an R2 bucket using rclone or the dashboard. Then put a Worker in front of it to add the headers Apple and hls.js require. R2 alone won’t set the right MIME types or CORS, and Apple’s player is strict about both.

// Cloudflare Worker — minimal HLS-correct headers
const MIME = {
  'm3u8': 'application/vnd.apple.mpegurl',
  'aac':  'audio/aac',
  'mp3':  'audio/mpeg',
  'wav':  'audio/wav',
};

export default {
  async fetch(req, env) {
    const url = new URL(req.url);
    const key = url.pathname.slice(1);
    const obj = await env.PODCAST.get(key);
    if (!obj) return new Response('Not Found', { status: 404 });

    const ext = key.split('.').pop();
    const headers = new Headers();
    headers.set('Content-Type', MIME[ext] ?? 'application/octet-stream');
    headers.set('Access-Control-Allow-Origin', '*');
    headers.set('Access-Control-Expose-Headers', 'Content-Length, Content-Range');
    headers.set('Accept-Ranges', 'bytes');
    headers.set('Cache-Control', 'public, max-age=31536000, immutable');
    obj.writeHttpMetadata(headers);
    return new Response(obj.body, { headers });
  }
};

Three headers matter most. Content-Type: application/vnd.apple.mpegurl on .m3u8 files — without it, Safari refuses to play. Access-Control-Allow-Origin: * so hls.js previews work from any origin. Accept-Ranges: bytes so clients can seek into segments efficiently.

If you’d rather skip Workers entirely, a plain Backblaze B2 + bunny.net pull zone configuration works too — just remember to set the MIME mapping in your CDN’s settings panel, since static-file CDNs almost never know what .m3u8 is by default.

Point your RSS feed’s <enclosure url> at your master.m3u8. That’s the integration. Apple Podcasts, Overcast, and Pocket Casts will all pick up HLS audio enclosures correctly in 2026.

Validation — confirm it actually works before submitting

Three checks, in order:

QuickTime. Drag the master.m3u8 URL into QuickTime Player (File → Open Location). If it plays with a working scrubber, your MIME types and segments are correct. If it doesn’t, 90% of the time it’s a missing application/vnd.apple.mpegurl header.

hls.js demo page. Visit the public hls.js demo page, paste your master playlist URL, and watch the network tab. You should see segments downloading on demand as you seek — not the whole playlist front-loading. If everything downloads at once, segment duration is too short or your CDN is ignoring Accept-Ranges.

Apple Podcasts Connect validator. Once your RSS feed points at the HLS URL, run it through Podcasts Connect’s feed validator. It will catch missing CORS or MIME issues that the first two checks sometimes miss because Safari is more permissive than Apple’s submission pipeline.

If all three pass, you’re shipped.

FAQ

Do I need multi-rendition for an audio podcast? No. Adaptive bitrate matters for video where the difference between 480p and 1080p is enormous. For spoken-word audio at 96kbps, adaptive switching saves a few KB and adds complexity nobody hears. Ship single-rendition.

Can I embed transcripts? Not via HLS subtitle muxing — Mediabunny doesn’t write WebVTT into HLS, and Apple Podcasts reads transcripts from a separate <podcast:transcript> RSS tag anyway. Host your .vtt file alongside your segments and reference it in your feed. That’s the modern approach regardless of HLS.

What about chapters? Same answer: chapters belong in <podcast:chapters> JSON in your RSS feed, not muxed into the audio container. This is actually better — chapter art and links can update without re-packaging the episode.

Will this break older podcast apps? Apps that don’t speak HLS will fall back to the first segment URL or fail silently. In practice, every major podcast client added HLS audio support by 2024. If you’re worried about long-tail apps, keep a progressive MP3 mirror and serve via user-agent sniffing — but for >99% of listeners, HLS-only is fine in 2026.

What about DRM? Mediabunny doesn’t write DRM-protected HLS. If you need FairPlay or Widevine for a paywalled podcast, you’ll need a commercial packager like Bitmovin or Mux. For free shows, DRM is theater anyway.

Is this really cheaper than Buzzsprout? A weekly show with 5,000 listeners on R2 + a Worker costs around $2/month. Buzzsprout’s equivalent tier is $24/month. Over a year, you save enough to buy a decent microphone — and you own your URLs forever, so you can switch CDNs without breaking every directory listing.

View all 10 articles in HLS, m3u8 & Stream Recording →

Try these AI tools