Free · Hands-on guide · ~9 min read · Updated 2026-08-12

ISO 8583 Bitmap Explained: Decode and Build It by Hand

The bitmap is the table of contents of every ISO 8583 message: 8 or 16 bytes that announce exactly which data elements follow. After this page you can take any hex bitmap and list its fields on paper — no tool required — and go the other way, turning a field list into the exact hex string. The only equipment you need is the one small hex-to-binary table below.

The three rules

Everything on this page follows from three facts:

One hex character is four bits. The primary bitmap is 16 hex characters = 64 bits = 8 bytes.
Bits are numbered 1 to 64, left to right. Not 0 to 63. Programmers instinctively count from 0, and that off-by-one produces a field list that is entirely wrong by one — the single most common bitmap mistake.
Bit N set means data element N is present — with one exception: bit 1 doesn't announce a data element, it announces that a second bitmap follows.

Keep this conversion table next to you; it is the only lookup the whole procedure needs:

Hex	Binary	Hex	Binary
`0`	`0000`	`8`	`1000`
`1`	`0001`	`9`	`1001`
`2`	`0010`	`A`	`1010`
`3`	`0011`	`B`	`1011`
`4`	`0100`	`C`	`1100`
`5`	`0101`	`D`	`1101`
`6`	`0110`	`E`	`1110`
`7`	`0111`	`F`	`1111`

Hex → field numbers, step by step

Take a real bitmap and walk it end to end:

7238400108C08000

The procedure:

Write the 16 hex characters in a row.
Under each character, write its 4-bit binary from the table above.
Number the bit positions 1, 2, 3 … 64 from the left.
Every position holding a 1 is a present field.

A shortcut that saves counting: hex character k covers bits 4(k−1)+1 through 4k. Character 1 covers bits 1–4, character 2 covers 5–8, character 11 covers 41–44, and so on. Here is the full walk:

Char #	Hex	Binary	Bits covered	Fields set
1	`7`	`0111`	1–4	2, 3, 4 (bit 1 = 0 → no secondary bitmap)
2	`2`	`0010`	5–8	7
3	`3`	`0011`	9–12	11, 12
4	`8`	`1000`	13–16	13
5	`4`	`0100`	17–20	18
6	`0`	`0000`	21–24	—
7	`0`	`0000`	25–28	—
8	`1`	`0001`	29–32	32
9	`0`	`0000`	33–36	—
10	`8`	`1000`	37–40	37
11	`C`	`1100`	41–44	41, 42
12	`0`	`0000`	45–48	—
13	`8`	`1000`	49–52	49
14	`0`	`0000`	53–56	—
15	`0`	`0000`	57–60	—
16	`0`	`0000`	61–64	—

Result: fields 2, 3, 4, 7, 11, 12, 13, 18, 32, 37, 41, 42, 49 — the shape of a typical authorization: PAN, processing code, amount, timestamp, STAN, times and dates, acquirer ID, RRN, terminal and merchant IDs, currency. What each of those numbers means is in the field quick reference; paste the same hex into the bitmap calculator and it draws all 64 bits so you can check your paper work bit by bit.

Two things to remember once the field list is in hand: the data elements follow in ascending field number order, and each element then has its own length rules (fixed, LLVAR, LLLVAR) — that layer is covered in reading field format notation.

Field numbers → hex, one byte at a time

Going the other way is easier if you stop thinking in 64 bits and start thinking in 8 bytes of 8 fields each:

Byte	1	2	3	4	5	6	7	8
Owns fields	1–8	9–16	17–24	25–32	33–40	41–48	49–56	57–64

For any field N: byte number = ⌈N/8⌉, and its position inside that byte = ((N−1) mod 8) + 1, counting from the left. Each position has a fixed hex weight — the byte's value is just the sum of the weights of the fields you set:

Position in byte	1	2	3	4	5	6	7	8
Hex weight	`80`	`40`	`20`	`10`	`08`	`04`	`02`	`01`

Worked example — build the bitmap for fields 2, 3, 4, 11, 41:

Byte	Owns fields	Present here	Bit pattern	Hex
1	1–8	2, 3, 4	`01110000`	`70` (40+20+10)
2	9–16	11 → position 3	`00100000`	`20`
3	17–24	—	`00000000`	`00`
4	25–32	—	`00000000`	`00`
5	33–40	—	`00000000`	`00`
6	41–48	41 → position 1	`10000000`	`80`
7	49–56	—	`00000000`	`00`
8	57–64	—	`00000000`	`00`

Read the hex column top to bottom:

7020000000800000

Spot-check the two non-obvious fields: field 11 → byte ⌈11/8⌉ = 2, position (11−1) mod 8 + 1 = 3, weight 20. Field 41 → byte ⌈41/8⌉ = 6, position (41−1) mod 8 + 1 = 1, weight 80. Type 2,3,4,11,41 into the calculator's fields box and the same hex comes back.

The secondary bitmap: what bit 1 really means

Bit 1 is not "DE1 is present". Bit 1 set means another 8-byte bitmap immediately follows the first one, and that second bitmap covers fields 65–128. DE1 is the secondary bitmap — it never appears as a data element in a parsed message, which is why no correct decoder ever lists "field 1" in its output.

Decoding the second bitmap uses exactly the same procedure, then add 64: position 1 of the secondary bitmap = field 65, position 6 = field 70, position 64 = field 128.

Here is the smallest real message that needs one — a network echo test (0800), the same message dissected in real message examples:

8220000000000000 0400000000000000

Piece	Hex	Binary	Meaning
Primary, char 1	`8`	`1000`	Bit 1 set → a secondary bitmap follows
Primary, char 2	`2`	`0010`	Bit 7 → DE7 (transmission date & time)
Primary, char 3	`2`	`0010`	Bit 11 → DE11 (STAN)
Secondary, byte 1	`04`	`00000100`	Position 6 → 64 + 6 = DE70 (network mgmt code)

Fields present: 7, 11, 70. Because DE70 sits above 64, even this tiny three-field message must carry 16 bytes of bitmap. Open the full 0800 in the parser →

Mistake 1: reading data as a secondary bitmap

Sixteen bytes of hex in front of you does not mean sixteen bytes of bitmap. The first bit decides. Take the opening of the 0100 authorization from the examples article — bitmap plus the first 16 characters of data:

723C448028C08000 1640000012345678

The first character is 7 = 0111 — bit 1 is clear, so the bitmap ends after 16 characters. What follows (16 then 4000001234…) is DE2: an LLVAR length of 16 and the start of the PAN. Force those 16 characters through the bitmap procedure anyway and you "discover" fields 68, 70, 71, 74, 100, 103, 107, 108, 110, 114, 116, 118, 119, 122, 123, 124, 125 — seventeen phantom fields that were never sent, and every real field after DE2 lands in the wrong place.

The warning sign is exactly that pattern: a scatter of high-numbered, rarely-used fields in an otherwise ordinary message. Paste the full 32 characters into the bitmap calculator and it flags it: bit 1 is 0, so the last 16 characters are not bitmap and get ignored.

Mistake 2: using fields 65–128 without setting bit 1

The mirror image, on the build side. Say the message needs DE90 (original data elements, used in reversals) on top of fields 2, 3, 4, 11, 41. It is not enough to append a second bitmap with position 26 set — bit 1 must come on too, which changes the very first byte:

	Bitmap	What a receiver does
Correct	`F020000000800000 0000004000000000`	First char `F` = `1111`: bit 1 on → reads 16 bytes, finds 2, 3, 4, 11, 41, 90
Bit 1 forgotten	`7020000000800000 0000004000000000`	First char `7`: bit 1 off → reads only 8 bytes, then parses `0000004000…` as the start of DE2 — every field from there on is garbage

Note the first byte: 70 became F0 because the bit-1 weight (80) was added. The receiving side won't reject the broken version as "bad bitmap" — it will fail later, deep inside the data, with a confusing length or format error. The calculator guards both directions: enter any field above 64 in the fields box and it sets bit 1 for you; paste a 16-character bitmap whose first character is 8 or higher and it warns that the secondary bitmap is missing.

Sanity checks you can do at a glance

Length is 16 or 32 hex characters. Nothing else is a bitmap. An odd count means you sliced the message at the wrong offset.
The first character decides the length. 0–7 → bit 1 clear → exactly 16 characters. 8–F → bit 1 set → there must be 32. A first character of 8+ with only 16 characters available means the value is truncated.
Field 1 never appears in a decoded field list. If a decoder shows "DE1", it is counting the indicator bit as a data element.
An implausibly dense bitmap means a decoding problem, not a rich message. Wall-to-wall Fs usually mean the wrong starting offset, or hex that is really ASCII/BCD read with the wrong encoding — the same bytes give completely different bitmaps under each. The parser scores encodings automatically, and the examples article has a checklist for messages that won't parse.
Know what your dump shows. In an ASCII-encoded message the bitmap travels as 16 text characters ("7238…"); in a binary message it is 8 raw bytes that only look like 16 characters once a hex viewer renders them. On paper both decode identically — the difference matters when you count byte offsets into the raw message.

Why a bitmap at all

ISO 8583 defines up to 128 data elements, but a typical message carries only 10–20 of them. A fixed layout would force every message to reserve space for all 128 — hundreds of wasted bytes per transaction, multiplied by billions of transactions. The bitmap spends 8 bytes (16 when fields above 64 are needed) to say "only these fields follow", so each message carries exactly what it needs, and a receiver can test "is DE55 present?" by checking a single bit before parsing anything. How the bitmap sits between the MTI and the data elements is laid out in how to read an ISO 8583 message.

👉 Prefer to see the bits drawn instead of drawing them? The bitmap calculator works both directions — hex to fields and fields to hex — and to watch a bitmap doing its job inside a full message, paste one of the real examples into the parser.