NDEF Hex Decoder: Understand Every Byte of Your NFC Tag Payload
1What Is NDEF and Why Do You Need a Decoder?
NDEF — NFC Data Exchange Format — is the binary data format defined by the NFC Forum for storing and exchanging information between NFC devices and tags. It is the universal language spoken by NFC tags, smartphones, and NFC-enabled readers worldwide. Understanding NDEF is essential for any developer, integrator, or technical user working with NFC technology. When you read an NFC tag with an app like NFC Tools, the app shows you the human-readable content (a URL, a text, a vCard). But behind that, the tag stores raw binary data — a sequence of bytes with a very specific structure defined by the NDEF specification. This tool lets you go behind the scenes: paste the raw hexadecimal representation of any NDEF message and see exactly how it is structured, record by record, field by field. This is invaluable when debugging NFC integrations. Maybe a tag is not being read correctly on a specific device. Maybe you want to verify that a programmed tag contains exactly the right payload. Maybe you are reverse-engineering a proprietary NFC tag to understand its structure. Or maybe you are learning the NDEF format and want to see how different record types are actually encoded in binary. This decoder does all of that — instantly, for free, without installing anything.
2How the NDEF Decoder Works: Parsing the Binary Structure
The decoder processes the hexadecimal input by parsing the NDEF message structure byte by byte, following the NFC Forum NDEF Technical Specification. Step 1 — Byte parsing: The hex string is converted to a byte array. Each pair of hex characters becomes one byte (e.g., 'd1' = 0xD1 = 209 in decimal). Step 2 — Record header parsing: The first byte of each record is the header byte. Its bits encode several flags: MB (bit 7) = Message Begin — set on the first record. ME (bit 6) = Message End — set on the last record. CF (bit 5) = Chunk Flag — for chunked records (rarely used). SR (bit 4) = Short Record — if set, payload length is 1 byte; if not, 4 bytes. IL (bit 3) = ID Length present. TNF (bits 2-0) = Type Name Format, values 0-7 defining the record type family. Step 3 — Fields extraction: After the header, the decoder reads the type length, payload length (1 or 4 bytes depending on SR flag), and optional ID length. Then it reads the type field, optional ID field, and finally the payload. Step 4 — Type interpretation: Depending on the TNF and type, the decoder interprets the payload. For TNF=1 (Well-Known) with type 'U', it decodes the URI. For type 'T', it decodes the language code and text. For TNF=2 (MIME), it displays the MIME type. All fields are shown with their hex and ASCII representations.
3When Do You Need an NDEF Decoder? Practical Use Cases
Developers and technical NFC users reach for an NDEF decoder in many situations. Debugging NFC tag programming: You programmed a tag with your app but it doesn't behave as expected on some devices. Copy the hex dump from NFC Tools (Android) using the 'Share raw data' function, paste it here, and immediately see if the NDEF structure is correct. Common issues include wrong TNF values, incorrect payload length bytes, or missing Message Begin/End flags. Verifying tag content before deployment: Before shipping 10,000 pre-programmed NFC tags to a client, verify the payload structure matches the specification. This is critical in industrial NFC deployments where tags are read by custom hardware readers that may be strict about format compliance. Reverse engineering proprietary tags: Some devices use NFC tags with non-standard or proprietary content. The decoder shows you the raw bytes, TNF, type, and payload of every record, helping you understand the format even when the vendor does not provide documentation. Learning NDEF structure: Students and developers learning NFC technology can use this tool to study how different record types are encoded. Generate a URL payload with the URL Generator, then paste it here to see exactly how the bytes are structured. This hands-on approach is much more effective than just reading the specification. Testing NFC reading applications: QA engineers testing NFC reading apps can use known NDEF hex payloads as test vectors, verifying that their app parses each record type correctly.
4NDEF Format Deep Dive: TNF Values and Record Types
The Type Name Format (TNF) field is the key to understanding what kind of data an NDEF record contains. There are 8 possible TNF values: TNF 0x00 — Empty: No type, no payload. Used as a placeholder in chunked records or empty NDEF messages. TNF 0x01 — Well-Known: The most common type. Uses short type names defined by the NFC Forum RTD specifications: 'U' for URI, 'T' for Text, 'Sp' for SmartPoster, 'act' for Action, 'hs' for Handover Select, 'hr' for Handover Request. TNF 0x02 — MIME Media: The type field contains a MIME type string (e.g., 'text/vcard', 'application/vnd.wfa.wsc'). Used for vCards, WiFi credentials, and any data with a standard MIME type. TNF 0x03 — Absolute URI: The type field contains a full URI string identifying the record type. Used in some enterprise NFC applications. TNF 0x04 — External Type: The type is a user-defined string in the format 'domain.com:typename'. Used for application-specific record types. TNF 0x05 — Unknown: Type is unknown or not applicable. The type length must be 0. TNF 0x06 — Unchanged: Used only in chunked records (CF=1) to indicate continuation records have the same type as the first chunk. TNF 0x07 — Reserved: Reserved by the NFC Forum for future use. Should not appear in current implementations. For Well-Known URI records, the first byte of the payload is the URI identifier code, which indicates the URL prefix (see the URL Generator tool documentation for the full prefix table).
5How to Get an NDEF Hex Dump from Your NFC Tags
To use the NDEF decoder, you first need to obtain the raw hex payload from a physical NFC tag. Here are the most common methods: Using NFC Tools (Android and iOS): Open NFC Tools, go to the 'Read' tab, tap your phone on the NFC tag. After reading, tap on the record you want to inspect, then look for the 'Share' or 'Raw data' option. Some versions show the hex directly in the record details view. Using NFC TagInfo by NXP (Android): This is the most detailed NFC diagnostic app available. After scanning a tag, it shows the complete NDEF message in hexadecimal under the NDEF tab. It also shows the tag chip type, memory map, and any locked/protected sectors. Using Android NFC API: If you are developing an Android app, read the tag's NDEF content using the NdefMessage.toByteArray() method, then convert to hex using a standard byte-to-hex utility. Log the result for debugging. Using Web NFC API: In Chrome for Android, use the NDEFReader API. The message.records array gives you each record, and you can access record.data as an ArrayBuffer to extract the raw bytes. Using a USB NFC reader: Plug a USB NFC reader (like ACR122U or ACR1252U) into a computer, use the reader's SDK or tools like nfcpy (Python) or libnfc to dump the tag content, then paste the hex here for analysis. Sample NDEF payloads for testing: URI record for example.com: d1010e5503 example.com (in ASCII hex). Text record 'Hello' in English: d1010b5402656e48656c6c6f
FAQFrequently Asked Questions
What does TNF mean in an NDEF record?
TNF stands for Type Name Format. It is a 3-bit field in the NDEF record header that tells the reader how to interpret the 'type' field of the record. The most common values are: 0x01 (Well-Known, used for standard NFC Forum types like URI and Text), 0x02 (MIME Media Type, used for vCards and WiFi), and 0x04 (External Type, used for application-specific data). The TNF value determines how the smartphone's NFC stack will parse and dispatch the record to the appropriate app.
Why does the decoded payload look like random characters?
If the ASCII representation of the payload shows unprintable characters or symbols, it means the payload contains binary data that is not plain text — this is normal for many NDEF record types. For example, vCard data uses printable ASCII, but some proprietary record types store binary-encoded data. The hexadecimal view is always accurate regardless of the content. The dots (.) in the ASCII view represent bytes below 32 or above 126 that are not printable ASCII characters.
Can I decode NDEF data from a Mifare Classic tag?
Mifare Classic tags use a different memory organization than NDEF-native tags like NTAG21x. Mifare Classic can store NDEF data, but it must first be read using a tool that handles the Mifare Classic authentication (Key A/B). Once you have the raw data bytes from the NDEF area of a Mifare Classic tag (typically starting at block 4, sector 1 after the MAD — Mifare Application Directory), you can paste those bytes here. For full Mifare Classic analysis, use our Mifare Memory Map tool.