August 11, 2026 · Comparison

iBeacon vs Eddystone: BLE Beacon Formats Compared

A BLE beacon is a small device that broadcasts advertising packets on a fixed interval and does nothing else. It does not accept connections. It does not pair. It does not serve a GATT tree. It just transmits, and any receiver in radio range can hear it. That sounds limiting, but the format of those advertising packets is what enables micro-location, contact tracing, indoor navigation, asset tracking, and the physical web.

Two formats dominate: Apple's iBeacon (2013) and Google's Eddystone (2015). They overlap in the most basic use case — emitting an identifier a phone can detect — but they diverge sharply on payload structure, telemetry, URL support, and ecosystem. This guide covers the byte layout of each format, how proximity is estimated from RSSI, the three Eddystone frame types, and how to detect a beacon from macOS with a CoreBluetooth scanner.

If you are new to BLE in general, our companion guide on GATT services and characteristics covers the connection-based model that beacons deliberately avoid.

What a Beacon Is

A beacon is a one-way BLE advertiser. Internally it is a small radio (typically a Nordic nRF52, Texas Instruments CC2640, or similar SoC), a battery, an antenna, and firmware that wakes up on a timer and transmits one advertising packet on each of the three advertising channels (37, 38, 39). After transmission it goes back to sleep. The advertising interval ranges from 20 ms in retail deployments to 1000 ms or longer in battery-constrained tags.

The defining trait is that a beacon never enters a connection. It uses the ADV_NONCONN_IND PDU type, which tells scanners this packet is non-connectable, non-scannable, just listen. Every phone in range can hear the same packet simultaneously. There is no per-receiver overhead, no pairing exchange, no GATT discovery.

Advertising Packets

A BLE advertising packet carries a 31-byte (BLE 4.x) or 255-byte (BLE 5 advertisement extension) payload structured as a sequence of AD structures. Each AD structure has a 1-byte length, a 1-byte type, and a payload. The relevant types for beacons:

• Flags (0x01): 1-byte bitmask. Beacons set LE General Discoverable Mode and BR/EDR Not Supported.
• Complete Local Name (0x09) / Shortened Local Name (0x08): ASCII device name.
• Complete List of 16-bit Service UUIDs (0x03) / 128-bit (0x07): which GATT services the device would expose if connected. Beacons that broadcast service data (like Eddystone) include their service UUID here.
• TX Power Level (0x0A): 1-byte signed int8, the calibrated RSSI at 1 meter.
• Manufacturer Specific Data (0xFF): 2-byte company identifier followed by free-form bytes. This is where iBeacon lives.
• Service Data (0x16): 2-byte service UUID followed by free-form bytes. This is where Eddystone lives.

A receiver parses the AD structures by type, looks at the manufacturer-specific data or service data, and dispatches on the format.

iBeacon Format

iBeacon is Apple's proprietary format, introduced in iOS 7 in 2013. It is carried inside Manufacturer Specific Data (AD type 0xFF) with the Apple company identifier 0x4C 0x00 (little-endian 0x004C) and a sub-type byte 0x02 followed by a length byte 0x15 (21 bytes of payload). The 21-byte payload is:

• 16 bytes — Proximity UUID: identifier for a fleet of beacons (for example, all beacons in a retail chain share one UUID).
• 2 bytes — Major: big-endian uint16, groups beacons within the UUID (for example, a specific store).
• 2 bytes — Minor: big-endian uint16, identifies an individual beacon (for example, a specific aisle or display).
• 1 byte — Measured Power: int8, the calibrated RSSI at 1 meter. Typically around -59 dBm.

The full iBeacon AD structure is therefore 25 bytes (1 length + 1 type + 2 company + 1 subtype + 1 sublength + 21 payload), which fits comfortably inside a 31-byte legacy advertising packet.

Apple does not publish a telemetry frame. To know the battery level of an iBeacon, you typically need a separate management app or a different beacon format.

Proximity from RSSI

The receiving phone does not get distance from an iBeacon. It gets RSSI (received signal strength in dBm) and the beacon's Measured Power (RSSI at 1 m). The phone estimates distance by plugging those numbers into a path-loss model:

distance = 10 ^ ((MeasuredPower - RSSI) / (10 * N))

where N is the path-loss exponent (2 in free space, higher indoors). Apple's Core Location framework buckets the result into four proximity zones: Immediate (essentially touching), Near (within a few meters), Far (further away or signal noisy), and Unknown (no recent measurement).

The zones are intentionally coarse. RSSI in real environments swings by 10 to 15 dBm just from phone orientation, body absorption, and multipath reflections off walls and floors. The path-loss model gives a number; the zone bucketing acknowledges that the number has wide error bars.

Eddystone Frame Types

Eddystone is Google's open beacon format, introduced in 2015. It is carried inside Service Data (AD type 0x16) with the GATT service UUID 0xAA 0xFE (little-endian 0xFEAA, the SIG-assigned Eddystone UUID). The first byte of the service data payload is the frame type. Eddystone defines three frame types: UID, URL, and TLM.

Eddystone-UID

The UID frame broadcasts a stable identifier for the beacon. The payload is:

• 1 byte — Frame type (0x00 for UID)
• 1 byte — TX power: calibrated RSSI at 1 m, int8.
• 10 bytes — Namespace: an organization-level identifier. Commonly the first 10 bytes of a SHA-1 hash of a domain or other string.
• 6 bytes — Instance: a per-beacon identifier within the namespace.
• 2 bytes — Reserved: must be 0x00 0x00.

So a UID is 16 bytes of true identity (10 namespace + 6 instance) plus the type and TX power bytes. A UID beacon does not carry a URL.

Eddystone-URL

The URL frame is the most distinctive Eddystone feature: it broadcasts a compressed URL that the receiver can open in a browser. This is the physical web. The payload is:

• 1 byte — Frame type (0x10 for URL)
• 1 byte — TX power
• 1 byte — Scheme prefix: one of 4 codes — 0x00 = http://www., 0x01 = https://www., 0x02 = http://, 0x03 = https://.
• Up to 17 bytes — URL: ASCII, with 7 expansion codes for common suffixes (0x00 = .com/, 0x01 = .org/, 0x02 = .edu/, 0x03 = .net/, 0x04 = .info/, 0x05 = .biz/, 0x06 = .gov/, 0x07 = .com).

The compression is necessary because the entire URL must fit in the service data, which in turn fits in a legacy 31-byte advertising packet. Realistic compressed URLs are about 17 characters.

Eddystone-TLM

The TLM frame carries telemetry about the beacon itself. It is interleaved with the UID or URL frame at a low rate (for example, one TLM for every nine UID frames). The payload is:

• 1 byte — Frame type (0x20 for TLM)
• 1 byte — Version (0x00)
• 2 bytes — Battery voltage: big-endian uint16, in millivolts. 0 if USB-powered.
• 2 bytes — Temperature: big-endian int16, in units of 0.1 degrees Celsius (signed).
• 4 bytes — Advertising PDU count: big-endian uint32, total packets transmitted since boot.
• 4 bytes — Uptime: big-endian uint32, 0.1-second ticks since boot.

TLM is what lets a fleet manager monitor thousands of beacons remotely — when the battery voltage starts dropping below 1000 mV, schedule a replacement.

iBeacon vs Eddystone

AltBeacon

AltBeacon (Radius Networks, 2014) is a third open format designed to remove the platform lock-in of iBeacon. It uses Manufacturer Specific Data with a configurable 2-byte company identifier and a 20-byte payload that includes a 16-byte beacon ID, 1-byte major reference, 1-byte minor reference, 1-byte TX power, and a 1-byte reserved mfr-id slot. In practice AltBeacon sees very little deployment; the ecosystem split ended up being iBeacon on iOS-centric deployments and Eddystone on Android- and cross-platform ones.

RSSI Distance Limitations

Every beacon-based distance estimate is an RSSI measurement dressed up with a path-loss model, and RSSI is messy:

• Multipath: indoors, the receiver hears the direct path plus reflections off walls and floors, which interfere constructively and destructively. RSSI swings by 10 or more dBm as the receiver moves centimeters.
• Body absorption: the human body is mostly water and attenuates 2.4 GHz strongly. A phone in a pocket reads 10 to 15 dBm lower than the same phone held up.
• Orientation: a phone antenna is not isotropic. Rotating the phone 90 degrees can swing RSSI by 5 dBm.
• Calibration drift: the beacon's Measured Power value is calibrated at the factory or by the deployer. If the beacon's antenna changes (for example, moved near metal), the calibration is wrong.
• Co-channel interference: many beacons in a small space raise the noise floor.

The practical consequence: never treat beacon RSSI as a precise distance. Use it to detect proximity (immediate, near, far) and to rank which beacon is closest among a known set. That ranking is robust even when the absolute distances are not.

Detecting Beacons on macOS

macOS exposes raw advertising packets through CoreBluetooth's CBCentralManager scan. The delegate callback centralManager(_:didDiscover:advertisementData:rssi:) fires for each advertising packet. The advertisementData dictionary contains:

• CBAdvertisementDataManufacturerDataKey — the manufacturer-specific data, with the company ID at the front. iBeacon lives here; check for 0x4C 0x00 and the 0x02 0x15 sub-prefix.
• CBAdvertisementDataServiceDataKey — a dictionary of service UUIDs to their service data. Eddystone lives here; look up 0xFEAA and inspect the frame-type byte.
• CBAdvertisementDataTxPowerLevelKey — the advertised TX power if present.
• CBAdvertisementDataRSSI (in the callback signature, not the dict) — the received signal strength.

A native macOS beacon tool like MacTools BLE Inspector parses both keys in real time, decodes iBeacon, Eddystone-UID, Eddystone-URL, and Eddystone-TLM, and renders the structured fields alongside the raw bytes. You verify your beacon's UUID/Major/Minor, your Eddystone namespace/instance, your compressed URL expansion, and your TLM telemetry counters without writing a single line of CoreBluetooth code. For background on what a beacon deliberately skips, see our guide on BLE GATT services and characteristics, and for the encryption story that beacons ignore entirely, see BLE pairing and bonding.

Use Cases

• Retail proximity marketing: iBeacon deployed in store aisles; an app shows product content when the customer enters the near zone of a specific beacon.
• Micro-location and indoor navigation: many beacons distributed across a venue; a phone ranks visible beacons by RSSI to estimate its position on a floorplan.
• Museum exhibits: Eddystone-URL beacons broadcast the exhibit page directly. The visitor taps the notification, the browser opens, no app required.
• Asset tracking: Eddystone-UID tags on pallets or equipment; gateways record which tag was last seen where. For the upstream MQTT pipeline that often ingests these events, see our guide on running an MQTT broker on macOS.
• Contact tracing (historical): the Apple/Google Exposure Notification system used rotating BLE identifiers, not classic beacons, but it borrowed the same advertising infrastructure.
• Presence detection for automation: a small beacon on a keychain triggers a HomeKit or Home Assistant rule when the front-door scanner sees it within near range.

Frequently Asked Questions

What is the difference between iBeacon and Eddystone?

iBeacon is Apple's beacon format that broadcasts a 16-byte UUID plus 2-byte Major, 2-byte Minor, and 1-byte TX power. Eddystone is Google's open format that supports three frame types: Eddystone-UID (namespace plus instance), Eddystone-URL (a compressed physical-web URL), and Eddystone-TLM (telemetry such as battery voltage and temperature). iBeacon is opaque without a database lookup; Eddystone-URL carries human-meaningful content in the packet itself.

Can BLE beacons be used for accurate distance measurement?

Not precisely. Beacons only expose RSSI (received signal strength) and a calibrated TX power value at 1 meter. Distance is estimated by comparing the two, but the path-loss model is noisy: multipath reflections, body absorption, phone orientation, and environmental changes introduce significant error. Beacons are reliable for proximity zones (immediate, near, far) but not for centimeter-accurate distance.

Do beacons require a Bluetooth connection?

No. Beacons use BLE advertising packets (typically ADV_NONCONN_IND) that are broadcast one-way. The receiver never connects, pairs, or bonds with the beacon. This is what allows a single beacon to be heard simultaneously by any number of phones within radio range, with no per-connection overhead.

How do I detect iBeacon or Eddystone on macOS?

Use a CoreBluetooth-based scanner that exposes the raw manufacturer data and service data fields of advertising packets. iBeacon appears as Apple manufacturer data with a specific 16-bit company code (0x004C) and a 0x0215 sub-type. Eddystone appears as service data on the GATT service UUID 0xFEAA, with a frame-type byte distinguishing UID, URL, and TLM payloads.

Further Reading

• BLE Debugging on macOS: nRF Connect Alternatives That Actually Work
• BLE GATT Services and Characteristics Explained: How Every BLE Device Is Structured
• BLE Pairing and Bonding: Security Explained
• MQTT Broker on macOS: Run One Without Homebrew or Terminal