"Bluetooth 7" does not exist yet. The specification that will bring HDT —up to 7.5 Mbps over Bluetooth Low Energy— is expected by the end of 2026, and some vendors are already announcing "Bluetooth 7-ready" chips.
If you are choosing a chip or module for a product, this matters more than it seems, because the version number is almost never what you should be looking at. What you should be looking at is which specific features the chip supports, and whether the other end of the link supports them too.
A Bluetooth version is a ceiling, not a guarantee. It tells you which features a chip may have, not which ones it has. Almost everything interesting added since 5.0 is optional.
Table of contents
What each version added
Since Bluetooth Low Energy appeared, every version jump has added specific features. That is the only part of each release that matters:
- 4.0: Bluetooth Low Energy is born. A new protocol, separate from the classic Bluetooth used in headphones, designed to send small amounts of data on very little power. This is where battery-powered IoT starts.
- 4.2: larger packets and secure pairing. The payload of each packet grows from 27 to 251 bytes, and LE Secure Connections brings pairing based on elliptic-curve cryptography.
- 5.0: 2M PHY and Coded PHY. One physical layer at twice the speed, and another that trades speed for range: up to roughly four times more under ideal conditions, at 125 or 500 kbps.
- 5.1 to 5.4: positioning, audio and large networks. Direction finding (AoA/AoD) in 5.1; isochronous channels and power control in 5.2, which are the foundation of LE Audio; and in 5.4, Periodic Advertising with Responses (PAwR), built for networks of thousands of electronic shelf labels.
- 6.0: Channel Sounding. Reliable distance measurement between two devices, far more accurate than estimating it from signal strength. It is what lets you tell whether an object is one metre away or ten.
- 6.2: the minimum connection interval drops from 7.5 ms to 375 µs. Twenty times less time between exchanges, which shows in any peripheral where latency matters.
- Next version: HDT. High Data Throughput, up to 7.5 Mbps over LE. This is what many already call "Bluetooth 7", even though that number has not been published.
The chart at the top of this article traces the same path. One detail to read it correctly: it was drawn before the numbering was settled, and the version shown as "5.5" was eventually published as 6.0. HADM, high-accuracy distance measurement, is what we now call Channel Sounding. The x.x and y.y columns are what comes next: HDT and longer packets (HL), and later higher frequency bands (HB).
The catch: almost everything is optional
The Bluetooth Core Specification does not require most of the above. A chip can claim "Bluetooth 5.3" and not support Coded PHY. It can claim 5.2 and have no isochronous channels, which means no LE Audio.
The version number tells you which edition of the specification the chip was qualified against. It does not tell you which optional parts were implemented. And the datasheet cover page, which is usually what makes it into the meeting, shows the number and little else.
A link only works with what both ends support
A radio feature only exists if both sides support it. If your sensor has long range and your customer's phone does not, you do not have long range. The connection falls back to whatever the two have in common or, worse, the phone does not even see the sensor if it only advertises on Coded PHY.
For products that talk to a phone this is critical, because you do not choose the other end. Your customer does, and the installed base of phones is anything but uniform: each model implements its own subset of features, and on top of that the operating system has to let your app use them.
With your own gateway, things change. If the other end is a gateway or receiver you design yourself, you control both sides and can use whatever you want. If it is the customer's phone, design for the most limited phone you intend to support.
What this means for a project
This is how we bring it down to earth when it is time to choose:
- A sensor that sends one reading a minute: any BLE 5.x will do. Sleep current decides, not the version: how much the chip draws while asleep and how long it takes to wake up, transmit and go back to sleep.
- Range across a factory floor or out in the field: Coded PHY, verified at both ends.
- Locating objects indoors: 5.1 if the angle is enough, 6.0 if you need distance through Channel Sounding.
- Audio: LE Audio or Bluetooth Classic, depending on which phones you need to support. LE Audio is more efficient; Classic works with practically all of them.
- A low-latency peripheral: 6.2, for the short connection interval.
- High data volume: today, 2M PHY. HDT cannot go into a product yet.
The usual mistake in the requirements
Writing "latest Bluetooth version" in the requirements and considering the matter closed.
What you need to specify is the list of specific features: which PHY, which advertising mode, whether you need LE Audio, Channel Sounding or short connection intervals. And you need to check that list in three places, none of which is the datasheet cover page:
- The Bluetooth SIG qualification listing, which records what was qualified for that specific design.
- The vendor's SDK. A feature the silicon supports but the stack does not expose does not exist for you.
- The other end: the phones or gateways the product has to talk to.
Quick test: open your product's requirements document and find the Bluetooth line. If it states a version number and no features, that requirement has not been written yet.
Is the latest version worth it?
For most products that talk to a phone, a well-chosen BLE 5.0 part is more than enough. Going for the latest only pays off if you need a specific feature that only exists there.
It is also worth checking when that chip enters mass production. Some SoCs announced this month will not be available in volume until the second quarter of 2027. An announced chip is not a chip you can buy by the thousand, and designing around one that does not arrive delays the whole product. It is part of thinking about mass manufacturing from day one.
The same goes for "Bluetooth 7-ready" chips: a vendor saying its silicon is ready for a specification that does not exist yet tells you nothing about which features it will have, or when it will be qualified.
How we approach it at RobotUNO
When a product includes Bluetooth, the chip follows from the requirements, not the other way round:
- We translate what the product has to do —range, battery life, latency, audio, which phones it talks to— into a list of specific BLE features.
- We check those features in the qualification listing and the SDK, and cross-check them against the phones that need to be supported.
- We look at volume availability and lead times before the schematic is closed, not after.
- We measure range and power consumption on the prototype, in the real environment, before signing off the radio.
It is one of the first decisions in any connected electronic product development project, and it shapes the PCB design, the battery and the app.
And if the product needs CE marking, the radio also falls under the Radio Equipment Directive (RED). Starting from a module with its radio tests already done saves work, although it does not exempt you from assessing the complete product. We cover this in the guide to CE marking and pre-compliance.
Frequently asked questions
Does Bluetooth 7 exist yet?
No. As of today there is no published specification with that number. The next version, which will bring HDT (up to 7.5 Mbps over Bluetooth Low Energy), is expected by the end of 2026. "Bluetooth 7-ready" chips are a vendor announcement, not a qualification.
Does a Bluetooth 5.3 chip have more range than a 5.0 one?
Not necessarily. Range depends on transmit power, sensitivity and the antenna, and the big jump comes from Coded PHY, which arrived with 5.0 and is optional in every later version. A 5.3 chip without Coded PHY does not reach further just because it is 5.3.
What is the difference between Bluetooth and Bluetooth Low Energy?
They are two different radios within the same specification. Classic Bluetooth (BR/EDR) is the one used in headphones and traditional audio; Bluetooth Low Energy, since 4.0, is the one used by sensors and most IoT. A chip can have one, the other or both (dual mode), and an LE-only device cannot talk to a Classic-only one.
Where do I check which features a chip supports?
In the Bluetooth SIG qualification listing, which records what was qualified for that design, and in the vendor's SDK documentation, which tells you which features the stack actually exposes. The datasheet cover page is good for ruling chips out, not for choosing one.
Should I wait for HDT if my product moves a lot of data?
It depends on when you need to manufacture. What is in production today is 2M PHY. If the product ships in the coming months, design around that: HDT will take time to reach chips available in volume and, above all, your customers' phones.
Choosing a Bluetooth chip for your product?
We can review your requirements with you, turn them into specific features, and check that the chip and the phones it has to talk to really support them.
