NDEF Message Builder: Create Multi-Record NFC Payloads Visually
1What Is a Multi-Record NDEF Message and When Do You Need One?
Most NFC tags contain a single record — a URL, a contact, or a WiFi credential. But the NDEF specification supports multi-record messages: a single NDEF message can contain several records of different types, all stored sequentially in the tag's memory. This opens up powerful possibilities that single-record tags cannot provide. A multi-record NDEF message allows you to combine different types of content. For example, a SmartPoster record (defined by the NFC Forum) is actually a multi-record NDEF message inside another NDEF record — it contains a URI record for the URL, plus one or more Text records for the title in different languages, plus an optional Action record specifying what to do with the URL. The NDEF Builder tool lets you compose these complex messages visually, without manually calculating byte offsets and header flags. You add records one by one, choose the type (URL or Text currently), fill in the value, and the tool calculates the correct NDEF binary structure for the complete multi-record message, including proper MB/ME flags, payload lengths, and TNF values for each record. This tool is primarily aimed at NFC developers and integrators who need to test multi-record tag content, experiment with NDEF structures, or generate test vectors for NFC reading applications.
2How the NDEF Builder Generates Multi-Record Messages
Building a multi-record NDEF message requires careful byte-level construction. The NDEF Builder automates this process. Key rules for multi-record NDEF messages: Only the first record has the MB (Message Begin) flag set to 1. Only the last record has the ME (Message End) flag set to 1. Middle records (if more than 2 records) have both MB and ME set to 0. Each record independently specifies its own TNF, type, payload length, and payload. The builder processes your records in order: For each URL record, it creates a Well-Known URI record (TNF=0x01, type='U') with the appropriate URI prefix code. For each Text record, it creates a Well-Known Text record (TNF=0x01, type='T') with the language code prepended to the text as per the NFC Forum Text RTD specification. Once all individual records are constructed, the builder concatenates them into a single byte array, setting the MB flag on the first record and ME flag on the last. The resulting byte array is converted to hexadecimal and displayed. The total message size is shown, which helps you determine if the payload fits within your target NFC tag's memory. NTAG213 supports up to 137 bytes, NTAG215 up to 504 bytes, and NTAG216 up to 888 bytes.
3Practical Use Cases for Multi-Record NDEF Messages
While single-record tags cover most everyday use cases, multi-record messages unlock more sophisticated NFC applications. SmartPoster implementation: An NFC tag on a movie poster can contain both the trailer URL and the movie title as a text record. Some devices display the title as the notification title when the tag is read, making the experience more polished. Multilingual content: Store the same text in multiple languages (English, Spanish, French) as separate Text records. The NFC stack on the reading device can select the appropriate language record based on the device's locale. URL + action record: Combine a URI record with an Action record (NFC Forum RTD Action) to specify what the reading device should do — open the URL in the browser, save it to bookmarks, or just display it. Developer testing: Generate NDEF messages with specific combinations of record types to test your NFC reading application's parser. Does your app handle 3-record messages correctly? Does it crash on empty records? The builder lets you create edge cases. Prototype without hardware: During NFC application development, use the builder to generate test payloads that you can feed directly into your app's NDEF parser without needing a physical tag. This speeds up development significantly. Custom enterprise records: Combine a URL record (for a product page) with an External Type record (for an internal product ID) so a single tag scan both opens the web page and captures the product ID in your enterprise app.
4NDEF Multi-Record Technical Specification Details
Understanding the byte-level structure of multi-record NDEF messages is essential for developers implementing NFC parsers or verifying tag content. The NDEF message structure for multiple records follows these rules from the NFC Forum NDEF Technical Specification v1.0: Record header flag combinations: First record only: MB=1, ME=0. Last record only: MB=0, ME=1. First AND last (single record): MB=1, ME=1. Middle records: MB=0, ME=0. For a 2-record message (URL + Text), the binary layout is: [URL_record_header with MB=1,ME=0][URL_type_length][URL_payload_length][URL_type][URL_payload][TEXT_record_header with MB=0,ME=1][TEXT_type_length][TEXT_payload_length][TEXT_type][TEXT_payload]. Text record structure (TNF=0x01, type='T'): The payload starts with a Status Byte that encodes the UTF encoding (bit 7: 0=UTF-8, 1=UTF-16) and the language code length (bits 5-0). Then comes the IANA language code (e.g., 'en', 'es', 'fr') in ASCII, followed by the text content in the specified encoding. Message size limits: The maximum theoretical NDEF message size is 2^32 - 1 bytes (4 GB) for long records. In practice, the limit is determined by the NFC tag's memory capacity. For the SR (Short Record) flag set to 1, the payload length is limited to 255 bytes per record.
5Supported Record Types and Future Extensions
The current version of the NDEF Builder supports URL and Text record types, which cover the most common multi-record use cases. Here is an overview of all standard NFC Forum record types and their potential future inclusion. Currently supported: URL record (TNF=0x01, type='U') — well-known URI record with prefix compression. Text record (TNF=0x01, type='T') — well-known text record with language code. Planned future additions: SmartPoster (TNF=0x01, type='Sp') — composite record containing URL + title text + optional action and icon. This is the standard for NFC advertising tags. MIME records (TNF=0x02) — arbitrary MIME payloads including vCard (text/vcard) and WiFi credentials (application/vnd.wfa.wsc). External Type records (TNF=0x04) — for application-specific namespaced record types used in enterprise NFC systems. Action record (TNF=0x01, type='act') — companion to SmartPoster, specifying the default action (open URL, save for later, or open with app). When combining records, always consider the total payload size. A URL + vCard combination can easily exceed NTAG213's memory. Always check the byte count shown after building the message and choose an appropriate tag chip accordingly.
FAQFrequently Asked Questions
How many records can an NDEF message contain?
The NDEF specification does not define a maximum number of records — theoretically any number is allowed as long as the total message size fits within the tag's memory. In practice, the memory limit of the tag chip constrains the number of records. An NTAG213 with 137 bytes can typically hold 1–2 records depending on content length. An NTAG216 with 888 bytes can hold 5–10 records. Most real-world applications use 1–3 records. More than 3 records in a single message is unusual.
Do all NFC-enabled phones support multi-record NDEF messages?
All NFC-compliant devices must support multi-record NDEF messages per the NFC Forum specification. However, how the device acts on a multi-record message depends on its NFC software stack. Android's NFC dispatcher processes the first matching record it finds — if the first record is a URI, it opens the browser. iOS similarly processes the first recognized record. Some exotic record types in a multi-record message may be ignored by mainstream operating systems, so always test on target devices.
What is a SmartPoster record and how do I create one?
A SmartPoster is a standard NFC Forum record type designed for NFC advertising tags — a poster or product that, when tapped, opens a URL with a human-readable title. It is technically a nested NDEF message: a Well-Known record (TNF=0x01, type='Sp') whose payload is itself an NDEF message containing a URI record and one or more Text records (for the title in different languages). The NDEF Builder will add SmartPoster support in a future update. For now, you can combine a URL and Text record as a close approximation.