Flags
0x01 · 3 B02 01 06
All developer tools
BLE Advertisement Builder
Compose BLE advertising and scan response payloads from AD structures and beacon templates, with byte budgets, specification checks, and hex and C output.
Advertising mode
Legacy PDUs on channels 37, 38 and 39. An active scanner's SCAN_REQ is answered with SCAN_RSP.
Templates
Flags 0x06 and Manufacturer Specific Data for Apple (0x004C): type 0x02, length 0x15, proximity UUID, major, minor, measured power.
128-bit, not all zeros
0 to 65535
0 to 65535
-128 to 127
Scan response structures stay as they are.
Advertising Data
HCI_LE_Set_Advertising_Data10 / 31 octets · 21 remaining
AdvData field of the legacy advertising PDU.
16-bit Service UUIDs
0x03 · 4 BSeparate with spaces, commas or new lines. Sent little-endian, 2 octets each.- 0x181A Environmental Sensing
03 03 1A 18
TX Power Level
0x0A · 3 BSigned 8-bit, -127 to 127 dBm. Use the radiated power.02 0A 00
Scan Response Data
HCI_LE_Set_Scan_Response_Data23 / 31 octets · 8 remaining
ScanRspData field of SCAN_RSP, sent in reply to SCAN_REQ.
Local Name
0x09 · 23 B21 octets of UTF-8, 23 with the Length and AD type octets.16 09 45 6E 76 69 72 6F 6E 6D 65 6E 74 20 53 65 6E 73 6F 72 20 30 31
Validation
No errors or warnings
Advertising Data output
Open in decoder(opens in a new tab)10 / 31 octets · 21 remaining
Each color marks one AD structure. Hover a byte or a structure to highlight it.
02010603031A18020A00
- Flags0x01octets 0 to 2 · Length 0x02
02 01 06
- Flags
- LE General Discoverable Mode, BR/EDR Not Supported
- Complete List of 16-bit Service or Service Class UUIDs0x03octets 3 to 6 · Length 0x03
03 03 1A 18
- Service UUID
- 0x181A Environmental Sensing
- Tx Power Level0x0Aoctets 7 to 9 · Length 0x02
02 0A 00
- TX power
- 0 dBm
02 01 06 03 03 1A 18 02 0A 00
02010603031A18020A00
/* Advertising Data: 10 octets */
static const uint8_t adv_data[10] = {
/* Flags */
0x02, 0x01, 0x06,
/* Complete List of 16-bit Service or Service Class UUIDs */
0x03, 0x03, 0x1A, 0x18,
/* Tx Power Level */
0x02, 0x0A, 0x00,
};HCI_LE_Set_Advertising_Data takes a length of 10 and a fixed 31-octet parameter; the octets after the significant part are zero.
Scan Response Data output
Open in decoder(opens in a new tab)23 / 31 octets · 8 remaining
Each color marks one AD structure. Hover a byte or a structure to highlight it.
1609456E7669726F6E6D656E742053656E736F72203031
- Complete Local Name0x09octets 0 to 22 · Length 0x16
16 09 45 6E 76 69 72 6F 6E 6D 65 6E 74 20 53 65 6E 73 6F 72 20 30 31
- Complete name
- Environment Sensor 01
16 09 45 6E 76 69 72 6F 6E 6D 65 6E 74 20 53 65 6E 73 6F 72 20 30 31
1609456E7669726F6E6D656E742053656E736F72203031
/* Scan Response Data: 23 octets */
static const uint8_t scan_rsp_data[23] = {
/* Complete Local Name */
0x16, 0x09, 0x45, 0x6E, 0x76, 0x69, 0x72, 0x6F, 0x6E, 0x6D, 0x65, 0x6E,
0x74, 0x20, 0x53, 0x65, 0x6E, 0x73, 0x6F, 0x72, 0x20, 0x30, 0x31,
};HCI_LE_Set_Scan_Response_Data takes a length of 23 and a fixed 31-octet parameter; the octets after the significant part are zero.
Advertise the payload from an application
The SimpleBLE advertise recipe shows how to set advertised service UUIDs and manufacturer data, and which fields each platform allows.
Format
How an AD structure is encoded
Advertising data and scan response data share one format, defined in Core Specification Vol 3 Part C Section 11: a sequence of AD structures placed back to back. Each structure has three fields:
Length, one octet: the number of octets that follow, which covers the AD type and the AD data. It is never zero.AD type, one octet: an assigned number from the Bluetooth SIG, such as0x01for Flags.AD data,Length - 1octets, formatted as the Core Specification Supplement (CSS) Part A defines for that type.
Because Length is a single octet, one structure carries at most 254 octets of AD data. Multi-octet values defined by the SIG, including UUIDs, company identifiers and appearance values, are little-endian. Vendor payloads inside Manufacturer Specific Data or Service Data follow their own byte order: iBeacon major and minor and every Eddystone-TLM field are big-endian.
02 01 06 03 03 1A 18 02 0A 00
Three structures, 10 octets. 02 01 06 is Flags 0x06. 03 03 1A 18 is a Complete List of 16-bit Service UUIDs with 0x181A sent as 1A 18. 02 0A 00 is TX Power Level 0 dBm.
The legacy HCI commands take a fixed 31-octet parameter plus a length. Octets after the significant part are zero and are not sent over the air. Extended advertising commands take only the significant part.
Structures this builder encodes
| AD type | Name | AD data | CSS Part A |
|---|---|---|---|
| 0x01 | Flags | One octet of flag bits | 1.3 |
| 0x02 / 0x03 | Incomplete / Complete List of 16-bit Service UUIDs | 2 octets per UUID, little-endian | 1.1 |
| 0x06 / 0x07 | Incomplete / Complete List of 128-bit Service UUIDs | 16 octets per UUID, little-endian | 1.1 |
| 0x08 / 0x09 | Shortened / Complete Local Name | UTF-8 string | 1.2 |
| 0x0A | TX Power Level | sint8, -127 to +127 dBm | 1.5 |
| 0x16 | Service Data - 16-bit UUID | UUID, little-endian, then service data | 1.11 |
| 0x19 | Appearance | uint16, little-endian | 1.12 |
| 0xFF | Manufacturer Specific Data | Company identifier, little-endian, then vendor data | 1.4 |
The raw structure accepts any AD type with hex data, for types such as URI (0x24) or Service Data with a 128-bit UUID (0x21). The builder still applies the CSS placement rules to raw structures, so a raw Flags structure counts as Flags.
Budgets
Legacy and extended advertising budgets
The space available depends on the advertising event type, not only on the Bluetooth version. A scan response exists only for scannable event types: a scanner that receives a scannable advertisement sends SCAN_REQ (legacy) or AUX_SCAN_REQ (extended), and the advertiser answers with SCAN_RSP or AUX_SCAN_RSP. Passive scanners never request it.
| PDU | Event type | Advertising data | Scan response data |
|---|---|---|---|
| ADV_IND | Connectable and scannable undirected | 31 | 31 (SCAN_RSP) |
| ADV_SCAN_IND | Scannable undirected | 31 | 31 (SCAN_RSP) |
| ADV_NONCONN_IND | Non-connectable and non-scannable undirected | 31 | None |
| ADV_DIRECT_IND | Connectable directed | None | None |
| AUX_ADV_IND | Extended connectable undirected | 245 in one PDU, no chaining | None |
| AUX_ADV_IND | Extended scannable undirected | None | Up to 1650 (AUX_SCAN_RSP + AUX_CHAIN_IND) |
| AUX_ADV_IND | Extended non-connectable and non-scannable undirected | Up to 1650 (AUX_ADV_IND + AUX_CHAIN_IND) | None |
Legacy advertising
Legacy advertising PDUs are sent on channels 37, 38 and 39. ADV_IND, ADV_SCAN_IND and ADV_NONCONN_IND carry up to 31 octets of advertising data, and SCAN_RSP carries up to 31 octets of scan response data. HCI_LE_Set_Advertising_Data and HCI_LE_Set_Scan_Response_Data accept a length from 0x00 to 0x1F. ADV_DIRECT_IND carries no advertising data, and ADV_NONCONN_IND is not scannable, so it never has a scan response. The same 31-octet limits apply when a legacy PDU type is selected through the extended advertising HCI commands.
Extended advertising
Extended advertising (Bluetooth 5.0) sends a short ADV_EXT_IND on the primary channels that points to an AUX_ADV_IND on a secondary channel. An extended advertising set cannot be both connectable and scannable (Vol 4 Part E Section 7.8.53), which leaves three undirected cases:
- Connectable: the advertising data must fit in one AUX_ADV_IND, because the AuxPtr field is not permitted there in connectable events. The PDU payload is at most 255 octets. After the Extended Header Length and AdvMode octet, the Extended Header Flags octet, AdvA (6 octets) and ADI (2 octets), at most 245 octets remain. TxPower or ACAD in the header reduce that, and a Controller returns Packet Too Long (0x45) for data that does not fit in the longest auxiliary advertising segment its current parameters allow. There is no scan response.
- Scannable: AUX_ADV_IND has no AdvData field in scannable events, so the set carries no advertising data. All data goes in the scan response, sent as AUX_SCAN_RSP and AUX_CHAIN_IND PDUs. The Controller refuses to enable a scannable extended set that has no scan response data.
- Non-connectable and non-scannable: the advertising data starts in AUX_ADV_IND and continues in AUX_CHAIN_IND PDUs. There is no scan response.
The total Host advertising data per set, before fragmentation, is at most 1650 octets (Vol 6 Part B Section 2.3.4.9). Each Controller reports its own limit through HCI_LE_Read_Maximum_Advertising_Data_Length, from 31 to 1650 octets. Set the builder's controller maximum to that value.
How the data is fragmented
There are two separate fragmentation steps. The Host sends at most 251 octets per HCI_LE_Set_Extended_Advertising_Data or HCI_LE_Set_Extended_Scan_Response_Data command, marking each command with an Operation value: 0x01 first fragment, 0x00 intermediate, 0x02 last, or 0x03 complete data. Fragmented writes are only accepted while the set is disabled. On air, the Link Layer fragments the data whenever it does not fit in one PDU with its extended header, and the Controller chooses the number and size of the fragments. An AD structure can be split across two or more PDUs.
On the receiving side, the Link Layer only requires a scanning Controller to store and report 251 octets of data from one advertisement or scan response (Vol 6 Part B Section 4.4.3.5). The builder warns when an extended payload goes past that size.
Flags
The Flags field
Flags (AD type 0x01, CSS Part A Section 1.3) is a bit field that states the device's discoverable mode and its BR/EDR support. The value is normally one octet, because all-zero octets after the last non-zero octet are omitted.
| Bit | Name | GAP usage |
|---|---|---|
| 0 | LE Limited Discoverable Mode | Set in limited discoverable mode, with bit 1 cleared. |
| 1 | LE General Discoverable Mode | Set in general discoverable mode, with bit 0 cleared. |
| 2 | BR/EDR Not Supported | Set by LE-only devices in the discoverable modes. |
| 3 | Simultaneous LE and BR/EDR to Same Device Capable (Controller) | Cleared in the discoverable modes, by LE-only and dual-mode devices. |
| 4 | Previously Used | Left at 0. |
| 5 to 7 | Not assigned | Left at 0. |
Rules the builder checks
- Flags shall be included when any flag bit is non-zero and the advertisement is connectable. An LE-only device sets bit 2, so a connectable LE-only advertisement carries Flags. Non-connectable advertisements may omit it, and a scanner then treats the flags as unknown.
- Flags is permitted once per advertising data block and is not permitted in scan response data (CSS Part A Table 1.1). Extended scannable events carry no advertising data, so they carry no Flags.
- GAP sets exactly one discoverable bit: limited discoverable mode sets bit 0 and clears bit 1, general discoverable mode does the reverse (Vol 3 Part C Sections 9.2.3.2 and 9.2.4.2). Non-discoverable and broadcast mode set neither.
- A central running the general discovery procedure ignores advertising data that has no Flags or has neither discoverable bit set. The limited discovery procedure only reports devices with bit 0 set (Vol 3 Part C Sections 9.2.5 and 9.2.6).
The common value 0x06 is LE General Discoverable Mode plus BR/EDR Not Supported. 0x05 is the limited discoverable equivalent, and 0x04 is an LE-only device that is not discoverable.
Placement
Advertising data versus scan response data
Advertising data is sent in every advertising event and reaches passive and active scanners alike. Scan response data is sent only when an active scanner requests it, and only for scannable event types. Data that a scanner needs to decide whether a device is relevant belongs in the advertising data; data it only needs after that decision can wait for the scan response.
- Advertising data: Flags, the service UUIDs or manufacturer data that scanners filter on, beacon frames, and values that change often, such as sensor readings in Service Data.
- Scan response data: static values such as the Complete Local Name, additional service UUIDs, TX Power Level and Appearance.
GAP gives the same guidance for legacy advertising: data that changes frequently should be placed in the advertising data and static data in the scan response data (Vol 3 Part C Section 9.2.4.2).
Placement rules
CSS Part A Table 1.1 limits how often each data type appears in one data block, where advertising data (AD) and scan response data (SRD) are separate blocks. Section 1.1.1 adds that a block contains at most one Service UUID list for each UUID size, complete or incomplete.
| Data type | Advertising data | Scan response data |
|---|---|---|
| Flags | Once per block | Not permitted |
| Service UUID list | One list per UUID size | One list per UUID size |
| Local Name | Once per block | Once per block |
| TX Power Level | May repeat | May repeat |
| Service Data | May repeat | May repeat |
| Manufacturer Specific Data | May repeat | May repeat |
| Appearance | Once, and not in both AD and SRD | Once, and not in both AD and SRD |
Local names that do not fit
A name is counted in UTF-8 octets, not characters: é takes 2 octets and most CJK characters take 3. When the complete name does not fit, use a Shortened Local Name (0x08). CSS Part A Section 1.2.1 requires it to contain contiguous characters from the beginning of the full name. A central reads the full name from the GAP Device Name characteristic after it connects. The builder offers to shorten an overflowing name to the octets that fit, without splitting a multi-octet character.
CSS Part A also says that GAP and GATT service UUIDs (0x1800 and 0x1801) should not be listed, and that 16-bit UUIDs are only used when the Bluetooth SIG assigned them. A vendor service uses a 128-bit UUID, which costs 18 octets as the only entry of a list.
Beacons
Beacon formats
The templates encode each beacon as ordinary AD structures, so every field stays editable after you apply one. All of them fit in legacy advertising data.
iBeacon
An iBeacon advertisement is Flags followed by Manufacturer Specific Data for Apple. It uses 30 of the 31 octets. Apple distributes the Proximity Beacon Specification under the iBeacon license.
| Octets | Field | Value |
|---|---|---|
| 0 to 2 | Flags | 02 01 06 |
| 3 | Length | 0x1A (26 octets follow) |
| 4 | AD type | 0xFF Manufacturer Specific Data |
| 5 to 6 | Company identifier | 4C 00 (Apple, 0x004C) |
| 7 to 8 | Beacon type | 02 15 (0x15 = the 21 octets that follow) |
| 9 to 24 | Proximity UUID | 16 octets in written order, not all zeros |
| 25 to 26 | Major | uint16, big-endian; 0 means not set |
| 27 to 28 | Minor | uint16, big-endian; 0 means not set |
| 29 | Measured power | sint8, average RSSI at 1 m in dBm |
02 01 06 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00 01 00 02 C5
Proximity UUID E2C56DB5-DFFB-48D2-B060-D0F5A71096E0, major 1, minor 2, measured power 0xC5 = -59 dBm.
AltBeacon
AltBeacon is a single 28-octet Manufacturer Specific Data structure sent in a non-connectable undirected PDU (ADV_NONCONN_IND), so the template also switches the event type. The specification recommends that the first 16 or more octets of the beacon ID are unique to the advertiser's organizational unit.
| Octets | Field | Value |
|---|---|---|
| 0 | AD length | 0x1B (27 octets follow) |
| 1 | AD type | 0xFF Manufacturer Specific Data |
| 2 to 3 | MFG ID | Company identifier of the beacon maker, little-endian |
| 4 to 5 | Beacon code | BE AC |
| 6 to 25 | Beacon ID | 20 octets |
| 26 | Reference RSSI | sint8, average RSSI at 1 m, 0 to -127 dBm |
| 27 | MFG reserved | 1 octet defined by the manufacturer |
Eddystone
Every Eddystone frame needs two structures: a Complete List of 16-bit Service UUIDs that contains 0xFEAA, and Service Data for 0xFEAA that carries the frame. The frame type is the high nibble of the first service data octet, and the low nibble is 0. The templates also add Flags 0x06, as in the example frame of the Eddystone protocol specification. Eddystone-UID then uses all 31 octets.
| Frame type | Name | Content after the frame type |
|---|---|---|
| 0x00 | UID | Ranging data (TX power at 0 m), 10-octet namespace, 6-octet instance, 2 RFU octets set to 0x00. Service Data length 0x17. |
| 0x10 | URL | TX power at 0 m, URL scheme code, 1 to 17 octets of encoded URL. |
| 0x20 | TLM | Version 0x00, battery mV, temperature as signed 8.8 fixed point, advertising frame count, uptime in 0.1 s. All big-endian. Service Data length 0x11. |
| 0x30 | EID | TX power at 0 m and an 8-octet encrypted ephemeral identifier that rotates. No template. |
Eddystone-URL compresses the URL: one octet selects the scheme, and single octets replace common top-level domains. The remaining characters must be printable US-ASCII, so the builder rejects spaces and non-ASCII characters. The encoded URL after the scheme code is 1 to 17 octets.
| Codes | Kind | Text |
|---|---|---|
| 0x00 to 0x03 | Scheme | http://www. https://www. http:// https:// |
| 0x00 to 0x06 | Expansion | .com/ .org/ .edu/ .net/ .info/ .biz/ .gov/ |
| 0x07 to 0x0D | Expansion | .com .org .edu .net .info .biz .gov |
| 0x0E to 0x20, 0x7F to 0xFF | Reserved | Not used for URL characters |
02 01 06 03 03 AA FE 0E 16 AA FE 10 EE 03 65 78 61 6D 70 6C 65 00
Frame type 0x10, TX power 0xEE = -18 dBm, scheme 0x03 = https://, then example and 0x00 = .com/.
Eddystone-TLM has no beacon ID. The specification says to interleave it with UID or URL frames, and a scanner links them by device address. The template encodes the unencrypted version 0x00; a battery value of 0 and a temperature of 0x8000 mean not supported.
Sources
Specification references
The encodings, limits and validation rules in this tool come from these documents. Decode any output with the advertisement decoder to check it field by field.
- Core Specification Supplement, Part A: data types and Table 1.1 placement rules
- Core Specification 6.2, Vol 3 Part C (GAP): Section 9.2 discoverable modes and Section 11 data format
- Core Specification 6.2, Vol 4 Part E (HCI): Sections 7.8.7, 7.8.8 and 7.8.53 to 7.8.57
- Core Specification 6.2, Vol 6 Part B (Link Layer): Sections 2.3 and 4.4.2
- Bluetooth Assigned Numbers: AD types, company identifiers, appearance values
- Apple iBeacon
- AltBeacon specification
- Eddystone protocol specification
- Eddystone-UID, Eddystone-URL and Eddystone-TLM frame specifications
Scope: the builder covers undirected advertising. It does not model directed advertising, periodic advertising or Additional Controller Advertising Data.