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.
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.
On this page
The short answer
- A codec has to be supported at both ends. Qualcomm's own description of aptX is explicit that the technology "must be incorporated in both transmitter and receiver to derive the sonic benefits". LDAC headphones plugged into an iPhone get no LDAC.
- SBC is the floor and it is mandatory. Every device that supports the Bluetooth audio profile A2DP has to implement SBC, so it is the fallback that always works.
- Apple devices support SBC and AAC, and nothing else. Apple's own support page puts the ceiling plainly: "Bluetooth connections aren't lossless."
- Android supports more, optionally. The Android Open Source Project documents AAC, aptX, aptX HD and LDAC as codecs a manufacturer may add on top of SBC — may, not must.
- Bitrate is a ceiling, not a delivery. LDAC advertises 990 kbps but Sony describes a "best effort" mode that drops to 660 or 330 kbps as conditions demand, and in a crowded radio environment it will.
- The real differences are practical, not sonic. Latency, connection stability and battery cost separate these codecs far more reliably than sound quality does.
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.
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.
Keep reading
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
| Codec | From | Documented rate | Where you find it | The catch |
|---|---|---|---|---|
| SBC | Bluetooth SIG | Up to ~512 kbps stereo; commonly far less | Everything, mandatory | Negotiated bitpool is invisible, so quality varies widely |
| AAC | MPEG | Typically ~250 kbps on Bluetooth | All Apple devices; most Android | Encoder quality differs by platform; costs battery to encode |
| aptX | Qualcomm | 352 kbps (44.1 kHz, 16-bit) | Android with Qualcomm silicon | Never on Apple devices |
| aptX HD | Qualcomm | 576 kbps (48 kHz, 24-bit) | Same, on supporting hardware | Still lossy; being superseded by Adaptive |
| aptX Adaptive | Qualcomm | ~279–420 kbps, variable | Recent Snapdragon devices | Rate drops when the link is busy — by design |
| aptX Lossless | Qualcomm | Up to ~1.2 Mbps, CD quality | Snapdragon Sound pairs only | Needs matching Qualcomm parts at both ends |
| LDAC | Sony | 990 / 660 / 330 kbps | Android 8.0 and later, widely | The 990 figure is a ceiling, not a promise |
| LC3 | Bluetooth SIG | Efficient at low rates by design | LE Audio devices | Needs 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.
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.
- Enable developer options by tapping the build number in the About phone screen repeatedly, then open Developer options.
- 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.
- 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
- Bluetooth SIG — A technical overview of LC3 (sample rates, frame intervals, the 160 kbps versus 345 kbps listening test)
- Bluetooth SIG — Advanced Audio Distribution Profile (A2DP) specification
- Android Open Source Project — Bluetooth services (codec support, licensing, LDAC in AOSP)
- Sony — LDAC developer site (990 kbps maximum, best-effort mode)
- Qualcomm — aptX audio technologies
- Apple Support — About lossless audio in Apple Music ("Bluetooth connections aren't lossless")
- aptX — documented bitrates, sample rates and latency figures for each variant
- SBC — bitpool presets, the 512 kbps stereo decoder requirement and SBC XQ
- SoundGuys — Understanding Bluetooth codecs (their LDAC best-effort measurements by handset)
- Archimago's Musings — Comparison of Bluetooth AAC encoder quality across platforms