Bluetooth codecs explained: SBC, AAC, aptX and LDAC

Headphone boxes advertise a codec the way cereal boxes advertise vitamins. The catch is that a codec is not a feature of the headphones at all — it is an agreement between them and your phone, and the agreement usually settles on the plainest option both sides understand.

Illustration of an audio stream being compressed at a phone and rebuilt at a pair of wireless earbuds

There is no wire between your phone and your earbuds, so the music has to be squeezed small enough to fit through a radio link. The thing doing the squeezing is the codec, and every wireless listening experience you have ever had went through one.

Which is why the marketing works. A codec name implies a quality tier, and the numbers attached — 990, 576, 352 — are large and comparable and satisfying. What the box cannot tell you is whether your phone will ever use that codec, whether the number will be reached in your living room, or whether you could hear the difference. Three separate questions, and all three answers are often no.

The short answer

What a codec actually does

A stereo CD-quality stream is about 1,411 kilobits per second of raw data. A classic Bluetooth audio link realistically carries a few hundred. The gap is the entire job.

So the phone throws data away. It analyses the music in short blocks, works out which detail the ear is least likely to notice, and spends its limited bits on what remains. The receiver rebuilds a waveform from that description. It is not the original waveform and never will be: every codec here except one is lossy by design.

Two consequences follow that the marketing tends to skip. The first is that your music was probably compressed already — a streaming service sends a lossy file, your phone decodes it, and a second codec compresses it again for the radio hop. That tandem coding is a better argument for a capable Bluetooth codec than any "hi-res" badge is: not more detail, but fewer artefacts of the second pass.

The second is that performance belongs to the encoder, not the name. Two devices can both be doing "AAC" and produce measurably different output, because the name specifies the bitstream and leaves the hard decisions to whoever wrote the encoder. The audio engineer behind Archimago's Musings compared AAC encoders across Android 10 and 13, Windows 11, iPhones and Macs in 2023 and found the results varied by platform. Those measurements are his, not ours.

Where a Bluetooth codec sits in the chain A streaming service sends a lossy file. The phone decodes it to audio, then a Bluetooth codec compresses it a second time for the radio link. The earbuds decode that second compression and drive the speakers. The codec name only describes the second compression step. THE CHAIN, STEP BY STEP 1. Streamed lossy file 2. Phone decodes it 3. Codec re-compresses 4. Radio hop to the buds 5. Buds decode it 6. Drivers move air The codec name on the box describes steps 3 to 5 only. Step 1 already threw data away, and step 6 is where most of the audible quality is decided.
Two lossy compressions happen in series. The codec debate is entirely about the second one, while the earbud's drivers and fit usually dominate what you hear.

Why both ends have to agree

When a phone connects to a pair of headphones, the two exchange lists of the codecs they can handle, and the source picks one from the overlap. That is the whole mechanism, and it explains most of the confusion in this area.

A2DP, the profile that carries stereo audio, makes SBC compulsory: as of A2DP 1.3 the Low Complexity Subband Coding remains the default and its implementation is mandatory for devices supporting the profile. Everything else is optional, which is why the overlap between two arbitrary devices so often contains nothing but SBC.

Android's documentation is blunt about that optional tier. The Android Open Source Project states that "in addition to SBC, Android 8.0 supports the following codecs: AAC, aptX, aptX HD, LDAC", and notes that manufacturers "might need to obtain separate licenses and binary blobs for some proprietary audio codecs" — LDAC excepted, because its encoder sits in AOSP itself. Which ones a given handset ships, and in what priority order, is a decision its manufacturer makes in a configuration file.

Apple decided otherwise and has stuck to it. iPhones, iPads and Macs negotiate AAC where the headphones support it and fall back to SBC where they do not. There is no aptX and no LDAC on iOS, whatever you spend.

How two devices choose a codec An Android phone offering SBC, AAC, aptX and LDAC, connected to headphones offering SBC, AAC and LDAC, will use LDAC because it is the highest priority codec in the overlap. An iPhone offering SBC and AAC connected to the same headphones will use AAC, because that is the best the overlap contains. THE OVERLAP DECIDES, NOT THE BOX Android phone SBC · AAC aptX · LDAC Headphones SBC · AAC LDAC They use LDAC (in the overlap) iPhone SBC · AAC Same phones SBC · AAC LDAC They use AAC LDAC is unused The same headphones, two different results.
Codec support is a property of the pair, not of either device. This is the single most useful thing to understand before paying extra for a codec badge.

Advertisement

The four you will actually meet

SBC is the universal one, and its reputation is worse than it deserves. A parameter called the bitpool decides whether it is mediocre or fine: documented presets sit at a bitpool of 53 for "high quality" at 44.1 kHz, while the decoder requirement extends to 512 kbps for stereo and the unofficial SBC XQ profile reaches around 551 kbps. Whether your devices negotiate a generous bitpool or a stingy one is invisible from outside, which is exactly the problem. SBC is not bad; it is unpredictable.

AAC is what Apple built its wireless audio around. It is a more modern design than SBC and generally sounds better at the same rate. Its weaknesses are the encoder variability above and a real computational cost, which comes out of the transmitting device's battery.

aptX is Qualcomm's family rather than a single codec. Classic aptX runs at 352 kbps, 44.1 kHz, 16-bit; aptX HD at 576 kbps and 24-bit; aptX Adaptive replaces both with a variable rate documented at roughly 279 to 420 kbps, trading quality against link robustness in real time and handling up to 96 kHz. aptX Lossless, announced in 2021, is the exception to the lossy rule: CD quality at 16-bit, 44.1 kHz, scaling to around 1.2 Mbps when the link allows. All of it needs Qualcomm silicon at both ends.

LDAC is Sony's, and it carries the biggest number. Sony's developer documentation describes transmission "at the maximum bitrate of 990kbps", with a best-effort mode that "controls bitrate automatically depending on the network condition, ensuring stable connection even in harsh environments" by stepping down to 660 or 330 kbps. It reaches 96 kHz and 32-bit and holds Hi-Res Audio Wireless certification at 990 kbps — and it is lossy at every one of those rates.

The codecs at a glance

CodecFromDocumented rateWhere you find itThe catch
SBCBluetooth SIGUp to ~512 kbps stereo; commonly far lessEverything, mandatoryNegotiated bitpool is invisible, so quality varies widely
AACMPEGTypically ~250 kbps on BluetoothAll Apple devices; most AndroidEncoder quality differs by platform; costs battery to encode
aptXQualcomm352 kbps (44.1 kHz, 16-bit)Android with Qualcomm siliconNever on Apple devices
aptX HDQualcomm576 kbps (48 kHz, 24-bit)Same, on supporting hardwareStill lossy; being superseded by Adaptive
aptX AdaptiveQualcomm~279–420 kbps, variableRecent Snapdragon devicesRate drops when the link is busy — by design
aptX LosslessQualcommUp to ~1.2 Mbps, CD qualitySnapdragon Sound pairs onlyNeeds matching Qualcomm parts at both ends
LDACSony990 / 660 / 330 kbpsAndroid 8.0 and later, widelyThe 990 figure is a ceiling, not a promise
LC3Bluetooth SIGEfficient at low rates by designLE Audio devicesNeeds LE Audio support at both ends

Why the bigger number often does nothing

Bitrate comparisons are only meaningful within a codec. Across codecs they are close to meaningless, because a better design gets more out of each bit — and the Bluetooth SIG demonstrated exactly that while introducing LC3. In its listening tests, SBC at 345 kbps scored just above 4.0 on the ITU-R BS.1116-3 impairment scale, while LC3 scored higher "with less than half the bit rate (160 kbps)". Half the data, better result.

The advertised number is also a ceiling the radio has to grant. Bluetooth shares the 2.4 GHz band with Wi-Fi, microwave ovens and every other pair of earbuds in the room, and adaptive codecs are adaptive because they have to be. SoundGuys, which measured this across handsets, reported LDAC's best-effort mode landing at 990 kbps on one phone, 660 on others and 330 on Google's Pixel 3 and 3 XL — and noted that at 330 kbps both aptX and plain SBC outperformed it. Their figures, worth knowing before you pay for the badge. The same congestion is one reason moving your Wi-Fi off 2.4 GHz can quietly steady Bluetooth as well.

Higher bitrates also mean more radio time and more processing at both ends, out of two batteries. If your earbuds run shorter on LDAC than on AAC, nothing is broken — that is the trade you chose, and it sits alongside the other habits that decide how long a battery lasts.

Documented bitrates compared with the raw CD-quality stream A raw CD-quality stereo stream is about 1411 kilobits per second. LDAC's top rate is 990, aptX HD is 576, aptX is 352, AAC on Bluetooth is around 250, and LC3 reached a better listening test score than SBC at 160. The bars show that every Bluetooth codec discards most of the raw data. KILOBITS PER SECOND, AS DOCUMENTED Raw CD stereo 1411 LDAC top 990 aptX HD 576 aptX 352 SBC (tested) 345 AAC, typical 250 LC3 (tested) 160 In the SIG's own tests the shortest bar beat the SBC bar above it. Length is not quality.
Bar lengths are the documented rates, not measured output. The teal bar is the point of the diagram: LC3 scored better than SBC on less than half the data.

Latency, the specification nobody prints

For anything with pictures attached, delay matters more than fidelity, and it is the one figure headphone boxes almost never carry. It is not the codec alone: encoding, buffering, the radio hop, decoding and the receiver's own buffer all contribute, and that buffer exists precisely to hide interference.

Qualcomm's aptX Low Latency was the one product built around the number, documented at roughly 32 ms end to end; Qualcomm has since retired it in favour of aptX Adaptive, documented at around 80 ms. That is the honest shape of the trade — the codec that resists interference does it by holding more audio before it plays.

Video apps compensate by delaying the picture to match the sound, which is why a film looks fine on earbuds that make a game feel mushy. Games and instruments cannot do that, because the sound has to answer an input. For those, the codec badge is the wrong thing to read; a cable or a dedicated low-latency dongle is the answer.

LC3 and LE Audio: the reset

The interesting development is not another proprietary codec with a bigger number. It is LC3, the codec the Bluetooth SIG made mandatory for LE Audio, which runs over Bluetooth Low Energy rather than the classic audio stack.

Its specification sounds unremarkable, and that is the point: sample rates of 8, 16, 24, 32, 44.1 and 48 kHz, bit depths of 16, 24 and 32, frame intervals of 7.5 or 10 ms. What it buys is efficiency, and efficiency at the low end unlocks the features — longer battery life at equivalent quality, several independent streams at once, hearing aids treated as first-class Bluetooth audio, and broadcast audio in public spaces.

The catch is the familiar one: LE Audio needs support at both ends and in the operating system between them, so the transition is arriving device by device. For headphones you expect to keep for years, LE Audio support is a more durable thing to look for than a proprietary badge, because it is where the standard itself is going.

How to see which codec you are using

You do not have to guess, at least on Android.

  1. Enable developer options by tapping the build number in the About phone screen repeatedly, then open Developer options.
  2. Find the Bluetooth audio codec entry while your headphones are connected and playing. The currently active codec is shown, and the list greys out anything the connected headphones do not support — which is the fastest way to learn what your pair can actually do.
  3. Do not force a codec permanently. The setting typically resets on reconnection, and forcing a high rate onto a marginal link produces the dropouts the adaptive modes exist to avoid.

On iOS and macOS there is no equivalent switch, because there is no choice to make: AAC where the headphones support it, SBC where they do not.

When it is worth caring

For most listening, on most earbuds, in most places, the codec is not the limiting factor. The drivers are, the fit of the tips is, the noise of the train is, and the lossy file the service sent you is. Paying to move from AAC to LDAC for listening on a bus is optimising the wrong link in the chain.

Three cases justify the attention. On good headphones, in a quiet room, with material you know well, the second compression pass is audible enough that a capable codec earns its place. If you play games or instruments, latency is the whole story and no codec on a standard Bluetooth link fully solves it. And if you are buying for the long term, LE Audio and LC3 are the specification worth having, because they are the one item on this list that is not a single company's ecosystem.

Everywhere else the useful conclusion is the dull one: check that both devices support something better than SBC, confirm it once in developer options, and stop thinking about it. The codec was never the part of the chain doing most of the work.

Sources

Share this guide X WhatsApp LinkedIn Email