ATR Parser

Parse smart card ATR bytes. Decode TS, T0, interface bytes, historical bytes per ISO 7816-3. Detect protocol T=0/T=1. Free.

Enter the Answer-to-Reset bytes in hexadecimal (spaces optional)

Byte Breakdown

Field Hex Description
Protocol
Convention
Historical Bytes

How to Use

  1. 1
    Capture the ATR from your card reader

    Insert the card into a PC/SC reader and trigger a cold reset (or use pcsc_scan, GlobalPlatformPro, or your reader's diagnostic utility) to capture the Answer-to-Reset bytes. The ATR is the response sequence the card emits between 400 and 40,000 clock cycles after RST goes high.

  2. 2
    Paste the ATR hex string into the parser

    Copy the ATR bytes (e.g. 3B 8F 80 01 80 4F 0C A0 00 00 03 06) into the input field. Spaces, colons, and dashes are stripped automatically. Or pick a preset (Java Card, MIFARE, SIM Card, EMV Payment) to load a known sample and see the decoded layout instantly.

  3. 3
    Read the byte-by-byte ISO 7816-3 breakdown

    The parser walks the ATR field by field — TS direction, T0 format byte, TA/TB/TC/TD interface bytes, historical bytes, and TCK XOR check — and labels each one with its meaning. The detected transmission protocol (T=0 character mode or T=1 block mode) and convention (direct vs inverse) are summarized at the top so you can identify the card class in seconds.

About

The Answer-to-Reset (ATR) is the very first conversation a smart card has with a reader. Defined by ISO/IEC 7816-3 for contact cards — and mirrored by the ATS (Answer To Select) in ISO/IEC 14443-4 for contactless cards — the ATR is a short byte sequence (typically 4–33 bytes) the card emits between 400 and 40,000 clock cycles after the reset line goes high. It tells the terminal everything it needs to know before any APDU is sent: which transmission protocol the card supports (T=0 character-oriented or T=1 block-oriented), the clock rate conversion factor Fi and bit rate adjustment factor Di, the guard time, the convention (direct 0x3B or inverse 0x3F), and a small block of historical bytes that often spells out the card OS or issuer in plain ASCII.

Structurally an ATR starts with TS (the convention byte), followed by T0 (the format byte) whose high nibble Y1 is a bitmap of which interface bytes are present and whose low nibble K counts the historical bytes. After T0 come optional TA1, TB1, TC1, TD1 interface bytes, each gated by the bits of Y1; the presence of TD1 then chains another nibble Y2 that controls TA2..TD2, and so on. A final TCK byte holds the XOR checksum of everything from T1 onwards (mandatory for T=1, optional for T=0-only cards). Decoding all of this by hand is tedious and error-prone, especially when you are debugging a stubborn reader, comparing a SIM card to a USIM, or trying to fingerprint an unknown EMV card in the field — which is exactly why this parser exists. Just paste the bytes, pick a Java Card, MIFARE, SIM Card, or EMV Payment preset, and the tool walks the structure for you, highlights the negotiated protocol, validates the TCK, and shows the printable ASCII embedded in the historical bytes so you can identify the platform at a glance.

FAQ

What is an ATR (Answer to Reset) and why does it matter?
An ATR is the byte string a smart card sends to the reader immediately after a reset (cold or warm) and before any APDU exchange. Defined in ISO/IEC 7816-3 for contact cards (and ISO/IEC 14443-4 ATS for contactless), it advertises the supported transmission protocol (T=0 or T=1), clock and divider parameters, guard times, and historical bytes that often identify the card OS or application. Without the ATR the reader would not know how to talk to the card at all — it is the first negotiation step of every PC/SC session.
What does the TS byte mean?
TS is the very first byte of the ATR and signals the bit-encoding convention. TS = 0x3B means direct convention (logic 1 = high level, least significant bit first), which is by far the most common on modern smart cards. TS = 0x3F means inverse convention (logic 1 = low level, most significant bit first) and is rare today, mainly seen on legacy SLE 4404-style memory cards. Any other value is invalid and the reader should reject the card.
How does protocol negotiation (T=0 vs T=1) work?
The card lists the supported transmission protocols inside successive TDi interface bytes. The low nibble of each TDi encodes one protocol number (0 = T=0 character protocol, 1 = T=1 block protocol, 14 = T=14 proprietary, 15 = T=15 global). The first protocol in the list is the default. The reader then issues a PPS (Protocol and Parameters Selection) request to lock in one of the offered protocols and the speed parameters (Fi, Di) carried in TA1, before any APDU is sent.
What are the historical bytes used for?
The historical bytes are an optional sequence (0–15 bytes; the K field in T0's low nibble) that the card uses to advertise itself. ISO/IEC 7816-4 defines a category indicator and compact-TLV encoding for life-cycle status, application identifiers, card capabilities, and issuer data. In practice many cards stuff a printable ASCII signature here — for example 'JCOP', 'NXP', 'JAVACARDOS', or an EMV manufacturer string — which is why the parser also shows the ASCII interpretation alongside the hex bytes.
What is a warm reset and how does it differ from a cold reset?
A cold reset re-applies VCC and the clock, then drives RST high — it is what happens when you insert a card. A warm reset keeps VCC and clock alive and only re-toggles the RST line. Both produce an ATR, but a card may return a different ATR after a warm reset to indicate a different mode (for example, switching from a negotiable to a specific protocol after PPS, or downgrading speed). ISO 7816-3 requires the card to answer within 40,000 clock cycles in either case.