ISO 14443 Type A vs Type B

ISO 14443 Type A vs Type B

ISO 14443 is the international standard governing contactless proximity smart card communication at 13.56 MHz. Within that standard, two distinct physical layer variants are defined: Type A and Type B. Both operate at the same radio frequency and support the same ISO 14443ISO 14443StandardStandard for contactless smart cards.Click to view →-4 APDU transport layer, but they differ in modulation scheme, coding, anticollision mechanism, and historical deployment — differences that matter significantly for hardware design, reader interoperability, and the product ecosystems built on each variant.

Overview

ISO 14443 Type A uses 100% Amplitude Shift Keying (ASK) modulation from reader to card, with Modified Miller coding for the bit stream. From card to reader, the data is transmitted via load modulation at a subcarrier of 847.5 kHz using Manchester coding. Type A's anticollision loop uses a bit-oriented binary search tree approach defined in ISO 14443-3. Type A is the foundation of the dominant contactless card ecosystems: NXP's MIFARE Classic, MIFARE DESFire, MIFARE Ultralight, NTAG series, and NXP's Jewel/Topaz are all Type A products. The MIFARE Classic's proprietary Crypto-1 layer sits above the Type A physical layer but is not part of the ISO standard.

ISO 14443 Type B uses 10% ASK modulation from reader to card (lower modulation depth), with NRZ-L coding. Card-to-reader load modulation uses a BPSK (Binary Phase Shift Keying) subcarrier at 847.5 kHz. Type B's anticollision uses a slot-based ALOHA protocol with a time-slot approach rather than the bit-oriented tree search of Type A. Type B is used in electronic passports (ePassport), French national ID cards, some banking cards, and Infineon's SLE 7x series.

Key Differences

• Reader-to-card modulation: 100% ASK / Modified Miller (Type A) vs. 10% ASK / NRZ-L (Type B)
• Card-to-reader modulation: Manchester subcarrier load modulation (Type A) vs. BPSK subcarrier load modulation (Type B)
• Anticollision: Bit-oriented binary tree (Type A) vs. slot-based ALOHA (Type B)
• Ecosystem: MIFARE, NTAG, FeliCa-adjacent (Type A) vs. ePassportePassportApplicationPassport with embedded contactless chip.Click to view →, government eIDeIDIdentityNational ID with embedded chip.Click to view →, some banking (Type B)
• Modulation depth: High (100% ASK, easy to detect) vs. low (10% ASK, requires more sensitive demodulation)
• Global market share: Type A overwhelmingly dominant (~80%+); Type B is a minority, primarily government documents

Technical Comparison

Anticollision Algorithms

The anticollision approaches represent a fundamental design philosophy difference.

Type A bit-oriented binary tree: The reader transmits a partial UID and cards with matching UID bits respond. Cards with collisions are progressively resolved by extending the bit depth of the selection command (ANTICOLLISION + SELECT loop). This approach resolves collisions deterministically and is efficient when card densities are modest.

Type B slot-based ALOHA: The reader broadcasts a REQB with a number of time slots (1–16). Each card in field randomly picks a slot and responds. If two cards pick the same slot, a collision occurs; the reader then issues further REQB commands to resolve remaining cards. ALOHA is more efficient with very large numbers of simultaneous cards (library inventory, warehouse scanning), but resolution is probabilistic.

For most transit and access control deployments (one or a few cards in field), both approaches perform equivalently. For high-density inventory scenarios, Type B's ALOHA scales better in theory, though ISO 15693's vicinity standard (with its own anticollision) is typically preferred for true inventory applications.

Use Cases

ISO 14443 Type A dominates in: - Transit fare collection (MIFARE Classic, MIFARE DESFire EV3 — London Oyster, Hong Kong Octopus, Berlin BVG, hundreds of other systems) - Physical access control (MIFARE-based HID iCLASS SE, dormitory cards, corporate badges) - NFC consumer products (NTAG213/215/216 for NFC tags, IoT pairing, product authentication) - Loyalty and gift cards (MIFARE Ultralight EV1) - Payment cards from some issuers using Type A SE chips

ISO 14443 Type B is used in: - ePassport chips (ICAO 9303ICAO 9303ComplianceICAO standard for ePassport chip data and security protocols.Click to view → specifies both Type A and B are acceptable, but many national programs chose Type B) - French Carte Nationale d'Identité (CNIe) - Some Belgian, Italian, and South African ID documents - European banking cards (some Visa/Mastercard contactless cards use Type B SEs) - Calypso transit smart cards (used in France, Belgium, Portugal)

When to Choose Each

Choose ISO 14443 Type A when: - Deploying transit, access control, or loyalty systems where MIFARE ecosystem compatibility is required - Using NFC Forum tag products (NTAG, ICODE) — all NFC Forum Type 2/4 tags are Type A - Building systems where large third-party product availability is a procurement priority - NFC smartphone emulation is needed (Android HCE and Apple NFC emulate Type A by default)

Choose ISO 14443 Type B when: - The deployment involves government eID or ePassport inspection (most ePassports are Type B) - The application requires Calypso-based transit integration (French/Belgian networks) - Specific national program requirements mandate Type B (check the country's eID specification) - Banking card SE selection by the card manufacturer results in Type B (often Infineon SLE 97-based)

Design readers to support both — modern NFC reader ICs (NXP PN532, PN5180, ST ST25R3911) support both Type A and Type B in a single reader design. There is no cost penalty for supporting both, and excluding Type B would prevent reading EU ePassports and several national ID programs.

Conclusion

ISO 14443 Type A and Type B converge entirely at the APDU application layer — an application designed for T=CL transport runs identically on both physical variants. The physical layer differences (modulation, coding, anticollision) are handled by the reader IC and card chip; application developers rarely interact with them directly. What matters in practice is ecosystem: Type A delivers access to the MIFARE product universe and NFC Forum tag ecosystem; Type B delivers access to ePassport and some government eID documents. Any production smart card reader implementation should support both without treating the choice as a design trade-off.