NFC Forum Tag Type Detector

NFC Tag Types and Detection

NFC tags follow ISO/IEC 14443 and NFC Forum specifications. Understanding tag types helps in choosing the right tag for your application and troubleshooting reading issues. The four NFC Forum tag types have different characteristics in terms of memory, speed, and compatibility.

Tag Type Overview

Type 1 Tags (Innovision Topaz) offer 96 bytes to 2 KB of memory, read-write capability, and are the cheapest option. Type 2 Tags (NXP MIFARE Ultralight) are the most common, with 48 bytes to 2 KB memory, read-write capability, and wide compatibility with Android and iOS. Type 3 Tags (Sony FeliCa) offer higher data rates and larger memory but are mainly used in Japan. Type 4 Tags (ISO 14443-4A/B) support up to 64 KB and are used for smart card applications including payment and identity.

Detection Process

When an NFC reader activates, it transmits a Request (REQA for Type A, REQB for Type B) to detect nearby cards. The card responds with ATQA/ATQB containing its UID and protocol parameters. After anti-collision (if multiple cards are present), the reader sends SELECT, and the card returns SAT (Select Acknowledge Type) indicating its compliance level. For Type 4 tags, the reader then uses ISO 7816-4 APDUs (SELECT, READ BINARY) to access files.

Common Use Cases

NFC tags are used in smart posters, business cards, access control, product authentication, and payment. NDEF (NFC Data Exchange Format) is the standard data format for storing URIs, text, and contact information on tags. Use our NDEF Parser to decode NDEF messages and NFC Capacity Calculator to check how much data fits on a specific tag type.

Anti-Collision and UID Structure

When multiple tags enter the reader field simultaneously, the anti-collision procedure prevents data corruption. For NFC-A (ISO 14443-3A), the reader issues REQA (0x26) and receives ATQA, then performs cascade levels based on UID length. A 4-byte UID requires one cascade level, while a 7-byte UID (common on NTAG and MIFARE Ultralight) requires two cascade levels, and a 10-byte UID requires three. The SAK byte returned after SELECT confirms the tag type. For NFC-B (ISO 14443-3B), the reader sends REQB with AFI (Application Family Identifier) to filter specific card types. NFC-F (FeliCa) uses a different polling command structure with system code-based filtering.

ATS (Answer To Select) Decoding

For ISO 14443-4 Type 4 tags, the ATS response follows ECMA-355 structure. The first byte is TL (total length), followed by T0 (format byte) encoding the presence of TA1, TB1, TC1 interface bytes, plus the historical bytes length. TA1 defines the bit-rate capability (divisor DSC and DRI), TB1 sets the frame waiting time and start-up guard time, and TC1 signals support for S-block chaining and node address/node time. For example, ATS 05 78 80 A0 02 20 90 00 breaks down as TL=5, T0=0x78 (TA1 and TB1 present, 8 historical bytes), TA1=0x80, TB1=0xA0. The historical bytes often contain a status word and AID reference that helps identify the card application.

SAK Bit-Level Interpretation

The SAK (Select Acknowledge) is a single byte where each bit carries specific meaning. Bit 0 (0x01) indicates compliance with ISO 14443-3 Type A. Bit 1 (0x02) marks Type 1 Tag (Topaz) compliance. Bit 3 (0x08) flags MIFARE Classic support with Crypto-1 authentication. Bit 4 (0x10) signals ISO 14443-4 compatibility (T=CL protocol, used by Type 4 tags). Bit 5 (0x20) indicates ISO 14443-4 support as well. Multiple bits can be set simultaneously — for instance, a MIFARE DESFire EV2 might return SAK 0x20, while MIFARE Classic 1K returns 0x08. Some cards set both 0x08 and 0x20, indicating dual-protocol support for both Crypto-1 and ISO-DEP layers.

ATR in Contact Smart Cards vs NFC

The ATR (Answer To Reset) defined in ISO/IEC 7816-3 is used by contact smart card readers. When an NFC reader presents a Type 4 tag via PC/SC, the ATR is synthesized from the ATS response. The first byte of ATR indicates the convention: 0x3B for direct (most significant bit first) or 0x23 for inverse. The T0 byte encodes both the presence of subsequent interface bytes (TA1, TB1, TC1, TD1) and the number of historical bytes. For NFC tags accessed through PC/SC, the historical bytes typically contain a compact representation of the RF technology and protocol used, as defined in PC/SC Part 3. This tool recognizes both direct ATR input and synthesized forms, allowing identification of contact smart cards and NFC Type 4 tags alike.

Manufacturer-Specific Patterns

Different manufacturers leave distinctive fingerprints in their tag responses. NXP MIFARE Classic cards respond with specific ATQA patterns and use Crypto-1 encryption with known default keys (Key A: FFFFFFFFFFFF, Key B: sector-specific). NXP NTAG series (213/215/216) feature a get_version command (0x60) returning chip type, memory size, and protocol information in 8 bytes. Sony FeliCa cards return IDm (manufacturer code + random number) and PMm (protocol parameters) instead of ATQA/SAK. Infineon technologies chips used in Type 4 tags include My-D Move and My-D NFC, with specific historical byte patterns. Identifying the manufacturer early helps with selecting the correct authentication key set and command sequence during application development.

Practical Debugging Tips

When a reader cannot detect a tag, first verify the frequency: NFC operates at 13.56 MHz, and antennas must be properly tuned. Check if the tag is a compatible type — some readers only support NFC-A, while others handle NFC-A/B/F/V. The SAK value 0x00 on NTAG tags means no MIFARE protocol support; if your reader expects MIFARE Classic authentication, it will fail on NTAG. For Type 4 tags, ensure the correct AID is selected before attempting file operations. The most common integration issue is UID-based access control relying on a 4-byte UID, which breaks when using NTAG tags with 7-byte UIDs. Always handle UID cascade properly and store the full UID rather than truncating it.