Bluetooth 7.0 vs. Bluetooth 6: how HDT reaches 7.5 Mbps and what supports it

Bluetooth Core Specification 7.0 is dated November 2, 2026. The Bluetooth SIG's feature overview was published on November 3, followed by the press announcement of HDT adoption on November 4. These are separate records: the specification, an explanatory document and a news announcement, rather than conflicting dates for one event.

Remembering only that Bluetooth 7 is coming in 2027 would blur this distinction. The Core specification already exists, but application specifications and implementations needed to build products on top of it take additional time. The SIG's 2027 outlook concerns the rollout of standardized high-quality wireless audio, HDT's first major application. It is not a promise of a particular phone or headphone launch.

Ask two separate questions: when was the standard established, and what works with the devices you intend to connect? The first half of this article explains the specification; the second examines documented implementation progress. This keeps future expectations separate from features available today.

The 6.x series contains several revisions: 6.0 and 6.3 do not define exactly the same capabilities. Channel Sounding, a prominent addition in 6.0, uses radio signals to estimate the distance between devices. HDT in 7.0 primarily changes their capacity to carry data. Measuring distance and transferring more information solve different problems.

This table selects representative changes, rather than listing every change and erratum. Version 7.0 does not abandon ranging to become an audio-only standard. It adds options for transport, control and encryption to the existing architecture. Instead of treating a version as a sound-quality grade, check the specific feature you need.

Our Bluetooth 6 guide to ranging and adoption explains PBR, RTT and the differences within 6.x. Here, we focus on HDT and the other additions in 7.0.

The physical layer, or PHY, defines how bits become radio signals and how a receiver recovers them. Legacy LE 2M operates at 2 Mbps. Comparing that with HDT's maximum gives 7.5 / 2 = 3.75 times the PHY rate. It does not mean file transfers are always 3.75 times faster, much less that audio sounds 3.75 times better.

HDT is an optional feature of Core 7.0. Even when HDT is implemented, HDT2, HDT3 and HDT4 are the baseline required rates; HDT6 and HDT7.5 require additional, optional support. There are also direction-specific requirements: receiving at 7.5 Mbps requires reception at 6 Mbps, while transmitting at 7.5 Mbps requires transmission at 6 Mbps and reception at 7.5 Mbps. An HDT label alone does not establish support for the highest rate.

The capabilities shared by the two devices and the radio conditions also matter. Buyers need to check HDT support, the required transmit and receive rates, and the device at the other end, not just the version number. Developers likewise need to handle the capabilities reported by the implementation instead of assuming a single fixed speed.

This HDT feature extends Bluetooth LE in the 2.4 GHz band. A combination chip's 5 GHz or 6 GHz Wi-Fi support, or separate proposals for Bluetooth in higher-frequency bands, should not be confused with the frequency band used by HDT itself.

A radio maps bits to signal states that the receiver can distinguish. Each such signaling unit is a symbol. Four possible states can represent 2 bits, eight states 3 bits, and sixteen states 4 bits. HDT uses π/4 QPSK, 8PSK and 16QAM modulation.

Adding states is not sufficient on its own. Noise and propagation can move the received signal away from its intended state, and the receiver still has to identify it. HDT therefore also uses forward error correction (FEC). Redundancy helps recover the information, but that redundancy must be transmitted too. Four bits per symbol does not mean four bits of application information in every symbol.

HDT sends two million symbols per second. Multiply this symbol rate by the bits per symbol and the effective code rate to obtain each PHY rate. The code rate is the fraction of encoded bits that represent information bits. A higher rate leaves a smaller fraction for redundancy.

HDT7.5: 2,000,000 × 4 × 15/16 = 7,500,000 bit/s = 7.5 Mbps. HDT2, by contrast, gives 2,000,000 × 2 × 1/2 = 2,000,000 bit/s. LE 2M and HDT2 are different PHYs despite both operating at 2 Mbps. Matching numbers do not imply the same radio implementation.

The implication is that the highest rate is not always the right choice. Data capacity must be balanced against the conditions needed to distinguish signal states reliably. An explanation of which rates work under which conditions is more useful than a headline maximum alone.

A transfer takes time for more than the data you want to deliver. Receiver synchronization, headers, responses and gaps between transmissions all contribute; errors can also require retransmission. Application throughput is the amount of data actually delivered divided by the total elapsed time.

HDT's improvements go beyond modulation. It can aggregate data and supports block-level acknowledgment and retransmission, making it easier to deal with a failed portion of a long transfer. However, products need not all use the same packet formats and additional features.

With short packets, HDT can even be slower than LE 2M. Nordic's technical explanation highlights the fixed time spent on synchronization and control. When little data is carried, this consumes a larger share of the transfer, so a higher maximum radio rate can still produce a worse overall result. Longer packets spread that cost across more data. The point at which HDT becomes advantageous depends on the implementation and radio conditions: compare the amount and frequency of data your application actually sends, rather than relying on a universal payload threshold.

For example, using decimal units, 1 MB is 8,000,000 bits. Sending only those bits at 7.5 Mbps gives an ideal calculation of about 1.07 seconds. Presenting that as a product's file-transfer time would be misleading. Control information, radio conditions and host processing add to the result. Comparisons need stated measurement conditions, including whether the file size uses MB or MiB.

The same caution applies to battery life. Finishing a transfer sooner can create more time for the radio to rest. Yet maintaining higher rates also takes processing, and the rest of the device consumes power. This is an opportunity to save energy, not a promise that every HDT product gains a fixed percentage of battery life.

Audio makes the bandwidth question concrete. Uncompressed PCM needs a data rate equal to sample rate × bit depth × channel count. Stereo uses two channels.

4.608 being less than 7.5 does not establish that every product can deliver lossless 96 kHz / 24-bit playback. Subtracting the audio data rate from the maximum PHY rate does not determine the required headroom or interoperability conditions. With lossless compression, the data rate also depends on the content.

HDT carries data; a codec represents audio. More transport capacity gives audio designers additional options, but it does not remove the need for compatible audio formats, profiles and implementations at both ends. HDT neither makes codecs unnecessary nor automatically improves an existing recording.

This distinction matters when deciding whether to replace a device. Buying one product labeled Bluetooth 7.0 does not unlock HDT if its partner or the software lacks the required support. Conversely, if your existing devices reliably provide the audio mode you want, the new version number alone is not a reason to replace them. Sound quality depends on more than the wireless specification version.

Another direction in 7.0 is adapting a connection while keeping it active. LE Isochronous Parameter Update (IPU) changes the transport settings of a Connected Isochronous Stream (CIS), a connection-based stream for time-coordinated delivery. Instead of rebuilding the stream, the devices coordinate a switch to a configuration prepared in advance. This may help with changing audio requirements or radio conditions, but it does not guarantee that every change is silent or latency-free.

Encryption Key Schedule (EKS) is a framework for deriving, separating and refreshing keys. Transient Application Key (TAK) lets a higher-layer application handle authentication and key establishment, with the resulting key used to encrypt the link. It offers an option for short-lived exchanges without relying on conventional pairing or long-term key storage. Not relying on pairing does not mean that verifying the other party is unnecessary.

Encryption Production Debugging (EPD) also adds support for analyzing encrypted traffic during development and interoperability testing. These additions support control, security and verification; treating them all as sound-quality improvements would miss their purpose. Each feature still needs an appropriate implementation and evaluation.

The primary sources establish several milestones: specification adoption, chipmakers' descriptions of HDT support, demonstrations in silicon and OS APIs. Adding these together still does not prove that a phone and earbuds available today can interoperate using HDT audio.

Qualcomm's page shows why the headline is not enough. The HDT feature name coexists with the specification-version entry and a draft footnote. We do not reinterpret that as a released Bluetooth 7.0 product. A manufacturer statement about final-specification conformance and the products using it would require a separate check.

Nordic's announcement shows progress beyond an idea to working silicon. However, it was published in October, before specification adoption. Its statement that the specification was expected later that year was the outlook at that time. The present status must be read alongside the SIG's November announcements.

On Android, BluetoothAdapter.isLeHighDataThroughputPhySupported() returns a support status, while constants such as BluetoothDevice.PHY_LE_HDT identify the HDT PHY. The APIs indicate progress in the development platform; they cannot add a new radio capability to hardware that lacks it. Software must handle unsupported and unknown states too.

Within the official materials reviewed, we did not verify a commercially available smartphone-and-earbud combination explicitly supporting HDT use, or a market adoption rate. This is not a survey of every product proving that no such combination exists. Nor do we label all iOS or Windows devices unsupported merely because we did not find documentation. Model- and region-specific official specifications are needed before adding further claims.

Whether to wait for Bluetooth 7.0 depends on the problem you need to solve. To measure the distance to a lost item, Channel Sounding implementation and app support matter more than HDT's peak rate. For music, consider the audio modes shared by your phone and listening device, connection stability and fit. Developers transferring large sensor logs or firmware need an evaluation environment that can measure HDT throughput and power consumption.

For small amounts of data sent frequently, such as individual sensor readings, keep LE 1M and LE 2M in the comparison. Distinguish a large log transferred in one batch from a sequence of short notifications. Evaluate waiting time and power consumption as well as speed for the actual workload.

• Feature: Does it support HDT, and the transmit and receive rates you need?
• Availability: Is it an announcement, prototype, SDK feature or an enabled function in a product?
• Partner and software: Do both ends, the OS, firmware and audio implementation support the intended use?
• Measurement conditions: Is the number a peak PHY rate or application throughput? Are distance, interference, retransmission and power conditions stated?

The version number also cannot tell you whether a software update will be enough. HDT cannot be added without the necessary radio circuitry; even with suitable hardware, the manufacturer must implement, enable and validate it. Neither a universal replacement requirement nor a universal software-upgrade promise is justified without product-specific evidence.

In short, Bluetooth 7.0 increases the data capacity of Bluetooth LE and expands adaptation during communication and key management. Establishing the standard is an important starting point. It becomes useful to an individual user when the two ends and their software work together. During the transition from Bluetooth 6 to 7, checking features, conditions and implementation maturity is more informative than following the new number alone.