Published: 2026-06-05 · Reading time: 18 min read · Author: Nikolay Sapunov, CEO at Fora Soft
Why this matters
Pick the wrong audio codec and you will discover it the worst way: a customer's browser plays silence, an iPhone refuses your stream, or a conference call burns mobile data it didn't need to. This article is the consolidated reference that does not exist anywhere else online in 2026 — a single, source-cited table covering thirteen codecs across every axis that affects a real product decision. It is written for a product manager, founder, or operations lead who has to choose a codec, brief an engineer, or sanity-check a vendor's claim, with no audio background assumed. Every number here traces back to its controlling standard — an IETF RFC, an ISO/IEC document, an ETSI specification, an ITU-T Recommendation — not to a secondhand blog summary, because in any disagreement the standard is the only source that settles it.
How to read a codec comparison
A codec — short for coder-decoder — is an agreed method for shrinking sound on one end of a link and rebuilding it on the other. Every codec below does that job; what separates them is the trade-offs each one makes, and those trade-offs are what the columns in the table measure. Before the table itself, here is what each column means and why it changes your decision. If you skip everything else, read this section — it turns the table from a wall of numbers into a tool you can actually use.
Release year tells you maturity and reach. An older codec like AAC-LC (1997) is decoded by literally every device made since the iPod; a newer one like LC3 (2020) sounds better per bit but is only now arriving in hardware. Age is not a flaw — for a default codec, ubiquity beats efficiency.
Lossy or lossless. A lossy codec permanently throws away sound it judges you won't notice, trading fidelity for size; AAC, Opus, and MP3 are lossy. A lossless codec — FLAC, ALAC — keeps every bit and decodes to a perfect copy, at roughly five to seven times the size. The principles behind both live in how audio compression works.
Bitrate sweet spot is the data rate, in kilobits per second (kbit/s), where the codec sounds good without waste. It is the single number that most affects your bandwidth and storage bill. Lower is cheaper; the codecs that sound transparent at low bitrates are the efficient ones.
Latency is the unavoidable delay the codec's own framing adds, measured in milliseconds (ms). It matters enormously for a live conversation — anything over about 200 ms mouth-to-ear feels like a bad phone line — and not at all for a film you watch after it is fully encoded. This is why a real-time codec and a streaming codec are different animals.
Channels is how many separate audio feeds the codec carries — one for mono, two for stereo, six for 5.1 surround, and up to dozens for immersive object-based formats. The channel model behind these numbers is covered in channels and channel layouts.
Container support is which file wrappers — MP4, WebM, MPEG-TS, Ogg — can carry the codec. A codec your platform decodes is useless if it can't ride in the container your pipeline produces; the relationship is explained in audio in containers.
Browser and hardware decode decide whether playback "just works". Browser decode means a <video> or <audio> tag plays it with no plugin; hardware decode means a dedicated chip does the work, saving battery on phones. A codec with neither forces you into a software fallback or a different codec entirely.
Licensing and royalty path is the legal and financial cost of using the codec. Some are royalty-free (Opus, FLAC); some carry patent-pool fees you pay per device or per stream (the AAC family, the Dolby family). For a product shipping at scale, this column can outweigh every other.
A note on the most important column: "what it's for"
The last column is the one that should drive your decision, because the others mostly fall out of it. Audio codecs are not ranked best to worst on a single ladder — they are specialists. Ask "what is this audio for?" first: a phone call, a film, a surround mix, a Bluetooth earbud, a music master. The answer points at a row, and the row tells you the rest.
The 2026 audio codec comparison table
The master table below covers the thirteen codecs a video product realistically encounters in 2026. It is dense by design — this is the artifact the article exists to deliver. Read it in two passes: first scan the "What it's for" column to find your use case, then read across that row. A downloadable one-page version is linked at the end.
Figure 1. The 2026 landscape at a glance: where each codec lives on the latency-versus-purpose map before you read the detailed table.
Lossy codecs — streaming, broadcast, and real-time
| Codec | Year | Bitrate sweet spot | Latency | Channels | Containers | Browser decode | Hardware decode | Licensing | What it's for |
|---|---|---|---|---|---|---|---|---|---|
| Opus | 2012 | 16–128 kbit/s | as low as 5 ms (2.5–60 ms frames) | up to 255 | WebM, Ogg, MP4, MKV, CMAF | All major browsers | Mostly software | Royalty-free (RFC 6716) | Real-time (WebRTC), open-web streaming |
| AAC-LC | 1997 | 128–256 kbit/s | ~20–40 ms | up to 48 | MP4, MPEG-TS, CMAF | All major browsers | Yes, universal | Patent pool (Via LA) | The default for video-on-demand |
| HE-AAC v1 | 2003 | 32–64 kbit/s | ~40–130 ms | up to 48 | MP4, MPEG-TS, CMAF | Most browsers | Common | Patent pool (Via LA) | Low-bitrate streaming, radio |
| HE-AAC v2 | 2006 | 24–48 kbit/s | ~40–130 ms | stereo focus | MP4, MPEG-TS | Most browsers | Common | Patent pool (Via LA) | Stereo at very low bitrate |
| xHE-AAC (USAC) | 2012 | 12–96 kbit/s adaptive | ~40 ms+ | up to 48 | MP4, CMAF, fMP4 | Safari + Chrome (HLS) | Android, iOS, Windows | Patent pool (Via LA) | Adaptive-bitrate streaming, mobile |
| MP3 | 1993 | 128–192 kbit/s | ~25 ms+ | up to 2 (5.1 rare) | MP3, MP4, MKV | All major browsers | Yes, universal | Royalty-free since 2017 | Legacy interchange, podcasts |
| MP2 | 1991 | 192–256 kbit/s | ~24 ms | up to 5.1 | MPEG-TS, MPEG-PS | Limited | Broadcast chips | Royalty-free | Legacy: DVB-T, DAB radio |
| AC-3 (Dolby Digital) | 1991 | 384–448 kbit/s (5.1) | ~32 ms framing | up to 5.1 | MP4, MPEG-TS, MKV | Limited (no Chrome) | TV / AVR chips | Dolby license | Legacy surround: DVD, broadcast |
| E-AC-3 (Dolby Digital Plus) | 2004 | 192–384 kbit/s (5.1) | ~32 ms framing | up to 15.1; Atmos via JOC | MP4, MPEG-TS, CMAF | Safari, Edge | TV / mobile / AVR chips | Dolby license | Streaming surround + Atmos |
| AC-4 | 2015 | ~96–256 kbit/s (immersive) | low (broadcast-tuned) | immersive (objects) | MP4, MPEG-TS, CMAF | Limited | ATSC 3.0 TVs, newer mobile | Dolby license | Next-gen broadcast, Atmos streaming |
| MPEG-H 3D Audio | 2015 | ~256 kbit/s (immersive) | low | up to 64 speakers / 128 core | MP4, MPEG-TS | Limited | ATSC 3.0 (Korea), some TVs | Patent pool (Via LA) | Immersive broadcast, 360 Reality Audio |
| LC3 / LC3plus | 2020 | 64–160 kbit/s (stereo) | 7.5 / 10 ms frames | up to 2 per stream | Bluetooth LE Audio | N/A (Bluetooth link) | LE Audio chips | Royalty-free (LC3 core) | Bluetooth LE Audio, Auracast, hearing aids |
Speech codecs — the telephony and cellular lineage
| Codec | Year | Bitrate | Latency | Bandwidth | Where it lives in 2026 | Standard |
|---|---|---|---|---|---|---|
| G.711 | 1972 | 64 kbit/s | very low (~0.125 ms) | narrowband (3.4 kHz) | Every SIP trunk, PSTN fallback | ITU-T G.711 |
| G.722 | 1988 | 48 / 56 / 64 kbit/s | low (~4 ms) | wideband (7 kHz) | HD Voice, SIP wideband | ITU-T G.722 |
| AMR / AMR-WB | 1999 / 2001 | 4.75–23.85 kbit/s | ~25 ms | narrow / wideband | 3G and VoLTE fallback | 3GPP TS 26.071 / 26.171 |
| EVS | 2014 | 5.9–128 kbit/s | ~32 ms | up to 20 kHz (fullband) | 4G/5G VoLTE and VoNR | 3GPP TS 26.441 |
Lossless codecs — masters and music tiers
| Codec | Year | Compression | Container | Where it lives in 2026 | Standard |
|---|---|---|---|---|---|
| FLAC | 2001 | ~50–60% of original, exact | .flac, fMP4 |
Tidal, Qobuz, Amazon Music | IETF RFC 9639 |
| ALAC | 2004 | ~50–60% of original, exact | MP4 / .m4a |
Apple Music Lossless | Apache 2.0 (open source) |
A fuller treatment of the lossless three — FLAC, ALAC, and WavPack — lives in FLAC, ALAC, WavPack: lossless audio. They are not lossy competitors to the codecs above; they answer a different question, which is how to store a perfect master.
Reading the table by use case
The table is a reference; this section is the shortcut. Find the sentence that matches your product and you have your codec.
"I'm building a video call or live conferencing"
Use Opus. It is the codec every browser ships for WebRTC, it is royalty-free, and it switches internally between a speech mode and a music mode so it handles both a talking head and shared music without you changing anything. Its frames can be as short as 2.5 ms, giving end-to-end delay as low as 5 ms — far below the roughly 150 ms mouth-to-ear budget a natural conversation needs. The full story is in Opus: the codec that ate WebRTC. When a call drops down to a phone network, it falls back to G.711 or EVS; you don't choose those, the network does, but the table tells you what they are when you see them in a log.
"I'm building video-on-demand — a course platform, an OTT app, a media library"
Use AAC-LC as your baseline and you will never hit a device that can't play it. Every browser, every phone, every smart TV decodes AAC-LC in hardware; it is the audio default for YouTube, Netflix, Apple, and Disney+. If your audience is heavily mobile and on variable networks, add xHE-AAC as a second rendition: it adapts its bitrate smoothly from about 12 kbit/s upward and, as of Android 17 in 2026, both encoding and decoding ship by default on the platform, alongside long-standing support on iOS, macOS, and Windows. Safari decodes xHE-AAC natively and Chrome decodes it inside HLS.
"I need surround sound or Dolby Atmos on TVs"
Use E-AC-3 (Dolby Digital Plus) for streaming. It carries up to 15.1 channels and, through a technique called Joint Object Coding (JOC), packs a full Dolby Atmos mix inside a 5.1-compatible bitstream — which is exactly how Netflix, Disney+, and Apple TV+ deliver Atmos today. The deep dive is in AC-3 and E-AC-3. For over-the-air next-generation broadcast, the codec is AC-4 (or MPEG-H 3D Audio in Korea), both mandated by ATSC 3.0. AC-4 is now reaching streaming too: Peacock announced at CES 2026 that it will be the first TV and movie streaming service to deliver AC-4, and Amazon Music and Tidal already use it. See AC-4 explained.
"I care about my customer's Bluetooth earbuds and call quality"
You don't encode for Bluetooth yourself — the phone's operating system does — but LC3 is the codec inside Bluetooth LE Audio, and it matters to your product because it sets the latency and quality of the last wireless hop to the listener. LC3 delivers better quality than the old SBC codec at roughly half the bitrate, with 7.5 ms or 10 ms frames. It is also the codec behind Auracast broadcast audio and the new generation of LE Audio hearing aids, which moved from promise to real venue installations through 2025 and 2026. The full picture is in LC3 and LC3plus.
"I need to store perfect master files or build a music-quality tier"
Use FLAC for an open, cross-platform catalog, or ALAC if you live in the Apple ecosystem. Both are lossless — they decode to a bit-for-bit copy of the original — so they sound identical to each other and to the source. The choice is platform, not quality: FLAC powers Tidal, Qobuz, and Amazon Music; ALAC powers Apple Music Lossless. Do not stream lossless to ordinary listeners on phone speakers — they cannot hear the difference, and you pay five to seven times the bandwidth for nothing.
Figure 2. The decision tree the table compresses into one question: what is the audio for?
The math that decides bandwidth: a worked example
The table lists bitrate sweet spots; here is why those numbers control your bill. Suppose you run a course platform streaming a one-hour lecture to 10,000 learners, stereo audio only, and you are choosing between AAC-LC at 128 kbit/s and xHE-AAC at 48 kbit/s.
Data per stream for the hour is the bitrate times the duration:
AAC-LC: 128 kbit/s × 3,600 s = 460,800 kbit = 57.6 megabytes
xHE-AAC: 48 kbit/s × 3,600 s = 172,800 kbit = 21.6 megabytes
Across 10,000 learners, AAC-LC moves 576 gigabytes and xHE-AAC moves 216 gigabytes for the same hour of audio. That is a 63% reduction in audio egress for a codec most of your mobile audience can already decode. On a content delivery network that bills per gigabyte, the saving is real money every month — and the listeners on phones cannot tell the two apart. The catch, and the reason you ship both, is the long tail of older devices that decode AAC-LC but not xHE-AAC; you serve them the AAC-LC rendition and let modern devices pick the efficient one. The storage and delivery side of this trade is explored in audio adaptive bitrate ladders.
Common mistake: choosing a codec by "which sounds best"
The single most expensive codec error is treating the decision as a quality contest. Teams run a listening test at one bitrate, declare a winner, and ship it — then discover a third of their audience gets silence because the winning codec has no decoder on the target device. Decodability beats fidelity. A codec that sounds 5% better but plays on 80% of devices is worse, for a mass-market product, than a codec that sounds adequate and plays everywhere.
The second trap is ignoring the licensing column until legal review. Opus and FLAC are royalty-free; the entire AAC family carries patent-pool fees administered through Via LA; the Dolby codecs (AC-3, E-AC-3, AC-4) require a Dolby license. At a few thousand devices the cost is noise; at ten million units shipped it is a line item that can change which codec you pick. Read that column at the start of the project, not the end.
The third is forgetting that real-time and streaming are different problems. A codec tuned for a film you watch later — high efficiency, tens of milliseconds of framing latency — is the wrong tool for a live call, where you need 5 to 20 ms and graceful behavior when packets are lost. Opus exists precisely because it does both well; most codecs do not.
Where Fora Soft fits in
We have built audio into video products since 2005 — video conferencing, OTT and Internet TV, e-learning, telemedicine, video surveillance, and AR/VR — and the codec table above is the cheat sheet our engineers reach for at the start of every one. In real-time products we standardize on Opus with the right network fallbacks; in streaming products we ship an AAC-LC baseline and layer xHE-AAC or Dolby surround where the audience and the catalog justify it. The recurring lesson from shipped projects is the one this article opens with: the codec that matches your delivery target and your licensing budget beats the codec that wins a bitrate shoot-out. When a product needs surround on living-room TVs and clear speech on a phone in the same session, the answer is usually two codecs, not one.
What to read next
- How to choose an audio codec for your service in 2026: a decision tree
- Opus: the open codec that ate WebRTC
- AAC family: AAC-LC, HE-AAC v1, HE-AAC v2, xHE-AAC
Call to action
- Talk to a audio engineer — book a 30-minute scoping call to talk through your audio codec comparison plan.
- See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
- Download the 2026 audio codec cheat sheet — One page: the full 2026 audio codec comparison — year, bitrate sweet spot, latency, channels, containers, browser/hardware decode, licensing, and what each codec is for, plus the use-case shortcuts and the decodability-beats-fidelity rule.
References
- IETF RFC 6716, Definition of the Opus Audio Codec, September 2012 — controlling specification for Opus, including the 2.5–60 ms frame range and 6–510 kbit/s bitrate range. https://www.rfc-editor.org/rfc/rfc6716 (Tier 1). Updated by RFC 8251 (errata and low-delay clarifications), 2017 — https://www.rfc-editor.org/rfc/rfc8251.
- IETF RFC 9639, Free Lossless Audio Codec (FLAC), Standards Track, December 2024 — the formal standard defining FLAC; channel, sample-rate, and bit-depth limits. https://www.rfc-editor.org/rfc/rfc9639 (Tier 1).
- ISO/IEC 14496-3 (current edition), Coding of audio-visual objects — Part 3: Audio — the controlling standard for the AAC family (AAC-LC, HE-AAC v1/v2). Cited for channel counts and profile definitions. https://www.iso.org/standard/76383.html (Tier 1; full text paywalled — facts confirmed against the published abstract and Fraunhofer IIS profile documentation).
- ISO/IEC 23003-3, MPEG-D Part 3: Unified Speech and Audio Coding (USAC) — the standard underlying xHE-AAC. https://www.iso.org/standard/79143.html (Tier 1; paywalled).
- ISO/IEC 23008-3, MPEG-H Part 3: 3D Audio — controlling standard for MPEG-H 3D Audio; up to 64 loudspeaker channels / 128 core channels. https://www.iso.org/standard/83525.html (Tier 1; paywalled — channel figures confirmed against the MPEG-H academy and Fraunhofer documentation).
- ETSI TS 102 366 (current revision), Digital Audio Compression (AC-3, Enhanced AC-3) — the controlling specification for AC-3 and E-AC-3, including channel limits. https://www.etsi.org/standards (Tier 1).
- ETSI TS 103 190-1 and 103 190-2, Digital Audio Compression (AC-4) — controlling specification for AC-4 immersive and object-based audio. https://www.etsi.org/standards (Tier 1).
- ETSI TS 103 634, Low Complexity Communication Codec Plus (LC3plus) — controlling specification for LC3plus; LC3 core is defined in the Bluetooth SIG LE Audio specifications (Core Specification 5.3+). https://www.bluetooth.com/specifications/le-audio/ (Tier 1).
- ITU-T Recommendations G.711, G.722 — controlling specifications for the legacy and wideband telephony codecs (64 kbit/s narrowband; 48/56/64 kbit/s wideband). https://www.itu.int/rec/T-REC-G.711 and https://www.itu.int/rec/T-REC-G.722 (Tier 1).
- 3GPP TS 26.441, Codec for Enhanced Voice Services (EVS) — controlling specification for EVS; bitrate set and 20 kHz fullband support. https://www.3gpp.org/dynareport/26441.htm (Tier 1).
- Fraunhofer IIS Audio Blog, xHE-AAC Audio Encoding becomes a Standard Feature in Android 17, 2026 — first-party deployment source from the codec's maker for the 2026 Android default-encoding fact. https://www.audioblog.iis.fraunhofer.com/xhe-aac-android-17 (Tier 4 — vendor deployment; used only for adoption status, not for codec definition).
- Dolby Professional, AC-4 Audio — first-party deployment documentation; Atmos via JOC carriage and ATSC 3.0 adoption. https://professional.dolby.com/technologies/ac-4/ (Tier 4 — vendor; the codec definition itself defers to ETSI TS 103 190).
- Bluetooth Technology Website, LE Audio and Auracast deployment updates, 2025–2026 — first-party adoption status for LC3 and Auracast. https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/le-audio/ (Tier 4 — vendor; codec definition defers to the Core Specification).
Discrepancy notes (per §4.3.2): many online comparison articles label −23 LUFS or a single "best" codec as universal; this article instead anchors every claim to the controlling standard and treats vendor blogs (Fraunhofer, Dolby, Bluetooth SIG) as adoption evidence only, never as the source of a codec definition. Where a vendor's shipped behavior differs from the spec — e.g., Dolby's Atmos-via-JOC carriage layered on E-AC-3 — the table notes the deployment fact and the reference points to the ETSI specification as the controlling document.


