APDU Builder

What this builder does

A command APDU (Application Protocol Data Unit) is the packet a host sends to a smart card or secure element under ISO/IEC 7816-4. Every command starts with a four-byte header — CLA (class), INS (instruction), and the two parameters P1 and P2 — and may optionally carry a command body and a request for response data. This tool takes those pieces, validates each one, and emits the exact byte sequence a reader will transmit over the contact or contactless interface. It is the inverse of the APDU parser: instead of decoding bytes into meaning, it composes meaning into bytes.

Crucially, the builder does not let you type a length field by hand. Lc is the length of the command data, so it is derived from the Data field automatically, and the tool chooses short or extended encoding based on the sizes involved. That removes the single most common source of a 6700 "wrong length" rejection.

When to use it

Reach for the builder when you are scripting a card personalisation flow, writing a test vector for a JavaCard applet, debugging a reader integration, or simply learning how the four cases differ. It is handy for hand-crafting a SELECT by AID before a transaction, a GET RESPONSE to retrieve buffered bytes after a 61xx status, or a VERIFY command while testing PIN handling. The example dropdown seeds realistic headers you can then tweak. Pair it with the CLA byte decoder when you are unsure which class byte to use, and the status word dictionary to interpret the card's reply.

Inputs and outputs

Each header field (CLA, INS, P1, P2) accepts exactly one byte written as two hex digits; spaces and a 0x prefix are tolerated and stripped. The Data field accepts any number of whole hex bytes and may be left empty. The Le control offers three choices: no Le at all, the maximum (a short 00 meaning 256, or extended 00 00 meaning 65536), or an exact decimal byte count. From those inputs the tool reports the detected case, the total byte length, the computed Lc, and whether extended length was triggered, then prints the full APDU as space-separated hex you can copy straight into a reader script.

Short vs extended length

Common mistakes

• Setting an Le byte of 00 expecting zero. In short form 00 means 256 bytes, not none. To request nothing back, choose "No Le".
• Editing Lc by hand. Lc must equal the data length. This tool computes it; a desynced Lc is the classic cause of a 6700 error.
• Odd-length data. The command body is whole bytes, so the hex must have an even number of digits.
• Assuming extended length always works. A card advertises extended-length support in its ATR or historical bytes; sending a 3-byte Lc to a card that only does short length will fail.
• Mixing up P1/P2 semantics. Their meaning is per-instruction. Check the command reference for the INS you are using rather than copying parameters between commands.

Related tools