NFC NDEF Memory Estimator

Count UTF-8 payload, NDEF record and Type 2 TLV overhead before the inlay is ordered, encoded or permanently locked.

NDEF record typeURI records use NFC prefix compression; text records include language metadata. Exact URI or textUse the final redirect destination or approved text, including non-ASCII characters. Language codeUsed only for text records; enter a short code such as en, ko or en-US. Usable NDEF data area (bytes)Use writable NDEF capacity from the exact chip/inlay documentation, not total EEPROM.

Enter the exact payload and usable tag capacity.

What this calculator solves

An NFC payload is not stored as only the visible URL or text. The record needs flags, type and payload-length fields; a Type 2 tag also needs an NDEF TLV and terminator. This estimator counts those bytes so a converter can screen tag capacity before procurement and show why a message does or does not fit.

How to choose the inputs

Paste the exact approved content because UTF-8 characters can consume more than one byte. URI mode applies the standard one-byte URI prefix code where a known prefix matches. Text mode adds a status byte and the entered language-code bytes. Capacity is the usable writable NDEF data area stated for the selected tag, measured in bytes.

How the calculation works

The tool builds a single URI or text record. A short record uses one payload-length byte up to 255 payload bytes; a longer record uses four. It then adds the type field, record header, Type 2 NDEF TLV tag and one- or three-byte TLV length plus terminator. It deliberately does not assume password, signature or proprietary application records.

Worked production example

The URI https://www.example.com/job/123 compresses the https://www. prefix into one code byte. The remaining ASCII content, URI record wrapper and Type 2 TLV use far less than a 144-byte data area, leaving space visible in the result. Replacing the path with multibyte text or adding records changes the answer.

How to interpret the result

Select an inlay whose documented usable NDEF memory exceeds the calculated total with an intentional project margin. Encode and scan the exact payload on the intended phone/device set, then preserve the read-back. If the customer needs analytics or changeable destinations, prefer a controlled short redirect URL rather than locking a long campaign URL into every label.

Common production mistakes

Do not compare visible character count with memory, use total chip EEPROM as writable capacity, omit the language code, or assume all URLs receive identical prefix compression. A tag can report sufficient bytes but still be locked, password-protected, formatted for another tag type or incompatible with the target device.

Production assumptions and limitations

This is a one-record Type 2 planning model for URI and text RTDs. It does not compose Smart Poster, MIME, signature, external-type, multi-record or proprietary application messages, and it does not write or lock a physical tag. Always compare with the encoder application's final byte count.

Related production workflow and source

Continue with the RFID Label Pitch Drift Checker and Smart Label Production Guide. NDEF structures follow NFC Forum record conventions and Type 2 TLV behavior documented in manufacturer implementations such as the ST NFC software toolbox. Last reviewed: 2026-09-02.