Wiegand 26 vs 34: What the Bit Split Actually Means

2026-09-30 · 1341 words

Wiegand is a wire, not a card format. A reader sends bits to a controller over two lines — DATA0 pulses for zeros, DATA1 pulses for ones, roughly 100 microseconds each with about a millisecond between them — and the controller reconstructs a number from the pulse count. No clock line, no packet length, no checksum. The "26" and "34" in Wiegand 26 and Wiegand 34 are simply the number of bits in that burst.

The part that causes trouble is what happens inside those bits. A frame carries a facility code, a card number, and two parity bits, and where the boundary between the two fields sits is a vendor convention, not something the frame declares. Two systems can read the same card, over the same wire, and disagree about who it is — with no error anywhere.

The frame, bit by bit

Wiegand 26   [P][ facility 8 bits ][ card number 16 bits ][P]
Wiegand 34   [P][ facility 16 bits][ card number 16 bits ][P]

             P = parity, one bit on each end of the frame

The 26-bit layout, used by HID H10301 and most 125 kHz proximity installations, is:

• bit 1 — even parity over bits 2–13
• bits 2–9 — facility code, 8 bits, 0–255
• bits 10–25 — card number, 16 bits, 0–65,535
• bit 26 — odd parity over bits 14–25

The 34-bit layout — HID H10306 and the AWID 34-bit credentials that share its shape — moves the boundary a long way:

• bit 1 — even parity over bits 2–17
• bits 2–17 — facility code, 16 bits, 0–65,535
• bits 18–33 — card number, 16 bits, 0–65,535
• bit 34 — odd parity over bits 18–33

So the card number is the same size in both. Everything the extra eight bits buy goes into the site field: 34-bit raises the number of distinct facility codes from 256 to 65,536. That is the whole difference, and it is the reason a site with more than 256 doors, tenants or buildings eventually migrates.

Why the boundary cannot be guessed

The frame length is agreed; the division is not. The same total can be split differently by different product families — 36-bit is a 17/17 site-and-card split in one, and an 8-bit site code with a 16-bit card number at entirely different bit offsets in another — and 34-bit credentials exist that use the same 16/16 shape but treat the site field as an issuer code rather than a facility code. Nothing in the transmission records which convention was used, which has a blunt consequence:

A controller configured for the wrong layout does not fail. It produces a different, valid number.

Feeding a 34-bit credential to a controller configured for 26 bits is the perfect example. The parser takes the first 26 bits of the burst: bit 1 becomes its even-parity bit, bits 2–9 become an 8-bit facility code that is really the top half of a 16-bit one, and bits 10–25 become a card number that is really the bottom half of the facility code followed by the top half of the real card number. The last eight bits of the frame, including the frame's own odd-parity bit, arrive after the parser has stopped reading. Almost always the parity check fails, the reader looks broken, and the card is perfectly fine.

The practical version of this, which turns up far more often than a hard failure, is a silent mismatch: a split that parses, passes parity and identifies a different person. With only 16 bits of card number, collisions are not theoretical. A site that has enrolled more than 65,535 credentials, or that reuses numbers across facility codes the panel can no longer see, ends up with two cards that are the same person to the controller — and the log will show a legitimate number for the wrong door.

Parity is the entire error-detection budget

Two parity bits over a 32-bit payload is a thin defence, and it is worth knowing exactly how thin.

Even parity over bits 2–13 means the twelve data bits plus the parity bit contain an even number of ones. If one pulse is dropped — a barrier motor starting up next to an unshielded run of cable is the classic cause — the bit count changes and the parity check fails. If two pulses are lost inside the same parity window, the count is even again and the frame passes. Wiegand has no way to notice, because there is nothing else in the frame to cross-check against: no length field, no sequence number, no CRC.

This is also why parity is computed over halves of the frame rather than the whole payload. Two 12-bit windows catch error patterns that one 26-bit window would not, at the cost of the two bits themselves. It is a 1950s answer to a 1950s problem, and it survives because the alternative — a bidirectional protocol — requires wires that the installed base does not have.

Reading a number out of a frame

Once a controller has the frame, the number it stores is the card number field, usually printed as decimal. That is where card-number formats start to blur: the same credential may be printed by one tool as a 26-bit decimal card number, by another as the raw hex of the whole frame — hex being a 1:1 representation of the bytes rather than an encoding, as the comparison of hex, Base32, Base64 and Ascii85 sets out — and by a third as a UID in reversed byte order. If the numbers you have in hand do not line up, the field boundary and the byte order are separate questions — Card Number Formats Explained walks the order to check them in, and the card number converter will show every form of a value you paste in, including the reversed reading that explains most "the system has the wrong number" tickets.

One useful sanity check before any of that: a 26-bit card number cannot exceed 65,535. If the number in your database is larger, it did not come from a 26-bit card number field — it came from a raw UID, a 34-bit-plus layout, or a mis-split frame.

You cannot convert 26 to 34

There is no arithmetic that turns a 26-bit credential into a 34-bit one, because nothing is being computed — a field boundary is being moved. Two honest options exist:

1. Reconfigure the panel to the format the credentials already use. This is a controller setting, and it is the cheap path when the reader, the cards and the panel all support the layout you are switching to.
2. Re-enroll the credentials into the new split, which means re-issuing or re-reading every card and rebuilding the access lists.

What does not work is "converting" the numbers: mapping a 900-series card number into a different facility code produces a credential that no card in the building carries. If a migration is on the table, the audit worth doing first is a count of distinct facility codes and the highest card number in use — those two numbers decide whether 34-bit is needed or merely convenient.

The security footnote that outlives the format

Wiegand is one-directional and unauthenticated. The reader talks; the controller listens; nothing is encrypted, and a facility code is printed on the card and known to anyone who has ever ordered credentials. 125 kHz proximity cards are also trivially clonable with commodity hardware, and because card numbers are usually sequential, an attacker who captures one frame has a good guess at its neighbours.

None of that is fixed by moving to 34 bits — it is fixed by replacing the protocol, which is what OSDP does: bidirectional, with a secure channel and encryption, so a reader can be authenticated and a cloned card alone is not enough. The reason 26-bit is still everywhere is not that it is good; it is that the wire, the readers and the doors are already installed, and the format travels with them.

If you are debugging a credential that reads differently on two systems, start with the bit split and the byte order — in that order. The frames are not lying; they are answering a slightly different question than the one being asked.