Skip to content
BLE·SNIFFER

BLE advertisement decoder

Paste a raw Bluetooth Low Energy advertising payload in hex and this page breaks it into its AD structures — naming each type, decoding the fields, and fixing the byte order that trips most people up. It runs on our server and nothing is stored.

Try:

19 bytes · 3 structures

  1. 0x01 Flags

    06
    Flags
    LE General Discoverable Mode, BR/EDR Not Supported

  2. 0x03 Complete List of 16-bit Service Class UUIDs

    0D 18
    UUID
    0x180D — Heart Rate

  3. 0x09 Complete Local Name

    48 65 61 72 74 20 52 61 74 65
    Name
    Heart Rate

How advertising data is structured

A BLE advertising payload is not a fixed record. It is a sequence of self-describing chunks, each laid out the same way: 

[length][AD type][data …]

The length byte counts the AD type byte plus the data bytes — not the length byte itself. So 02 01 06 means "two bytes follow: type 0x01 (Flags) with one byte of data, 0x06". Chunks sit back to back with no separator, and a decoder walks them by hopping forward length + 1 bytes at a time.

A legacy advertising packet carries at most 31 bytes of this data. Anything unused is commonly zero-padded, which is why a zero length byte is treated as the end of the real content rather than a malformed structure.

The byte-order trap

This is the single most common source of confusion. Multi-byte values in advertising data are little-endian — least significant byte first — but they are almost always written big-endian in documentation and specifications.

So the Battery service, UUID 0x180F, appears on the air as 0F 18. Apple's company identifier 0x004C appears as 4C 00. A 128-bit UUID is fully reversed: the Nordic UART service 6e400001-b5a3-f393-e0a9-e50e24dcca9e is transmitted as 9E CA DC 24 … 40 6E. If a UUID you look up returns nothing, try reversing the bytes before assuming the device is doing something unusual.

Reference: AD types

These are the assigned AD types this decoder recognizes. A type outside the list is still shown, with its data as raw bytes. Type and service names follow the Bluetooth SIG assigned numbers and are used here only to identify what a payload contains.

Type Name
0x01 Flags
0x02 Incomplete List of 16-bit Service Class UUIDs
0x03 Complete List of 16-bit Service Class UUIDs
0x04 Incomplete List of 32-bit Service Class UUIDs
0x05 Complete List of 32-bit Service Class UUIDs
0x06 Incomplete List of 128-bit Service Class UUIDs
0x07 Complete List of 128-bit Service Class UUIDs
0x08 Shortened Local Name
0x09 Complete Local Name
0x0A Tx Power Level
0x0D Class of Device
0x10 Device ID / Security Manager TK Value
0x11 Security Manager Out of Band Flags
0x12 Peripheral Connection Interval Range
0x14 List of 16-bit Service Solicitation UUIDs
0x15 List of 128-bit Service Solicitation UUIDs
0x16 Service Data - 16-bit UUID
0x17 Public Target Address
0x18 Random Target Address
0x19 Appearance
0x1A Advertising Interval
0x1B LE Bluetooth Device Address
0x1C LE Role
0x1F List of 32-bit Service Solicitation UUIDs
0x20 Service Data - 32-bit UUID
0x21 Service Data - 128-bit UUID
0x24 URI
0x25 Indoor Positioning
0x26 Transport Discovery Data
0x27 LE Supported Features
0x28 Channel Map Update Indication
0x29 PB-ADV
0x2A Mesh Message
0x2B Mesh Beacon
0x2C BIGInfo
0x2D Broadcast_Code
0x2E Resolvable Set Identifier
0x2F Advertising Interval - long
0x30 Broadcast_Name
0x31 Encrypted Advertising Data
0x34 Electronic Shelf Label
0x3D 3D Information Data
0xFF Manufacturer Specific Data

Where to get a payload to decode

Any scanner that shows you raw advertising bytes will do. On Android, BLE Sniffer logs the advertisements it sees and exports them, so you can paste real captures here. For the background on what you are looking at, see how BLE advertising works — it walks a payload byte by byte — and what a BLE sniffer is for how advertisement scanning differs from connection capture.