QR Code Format Information: The 15-Bit Pattern

The short answer

The format information is a small 15-bit pattern written around the three finder patterns of every QR code. It encodes the two things the scanner must know before it can read a single data module: the error-correction level (L, M, Q, or H) and the mask pattern (one of eight). The same 15 bits are written twice — once around the top-left finder and once split between the top-right and bottom-left finders — so that a damaged code still decodes. It is, in effect, a miniature error-correction layer for the metadata itself.

Because the scanner reads the format information before the data, the bits must keep their fixed dark/light geometry. You cannot recolor or restyle them the way you can recolor the data modules — break the format pattern and the scanner cannot determine the error-correction level or undo the mask, so decoding fails before the payload is ever read. The same structural rule applies as to the finder, timing, and alignment patterns: leave it alone. See our qr finder pattern, qr timing pattern, and qr error correction deepdive guides for the related structure.

What the format information actually is

The format information is a 15-bit sequence. Five of those bits are data and ten are error-correction bits computed from them using a BCH code — a compact Reed-Solomon-style checksum that lets the scanner recover the format even if several of the bits are obscured. The five data bits split into two fields: two bits select the error-correction level and three bits select the mask pattern (0 through 7). The full encode-decode pipeline, of which this is one stage, is walked through in our how does a qr code work guide.

Before the 15 bits are placed, they are XORed with a fixed mask pattern (101010000010010). This is not the data mask chosen by the encoder — it is a constant applied to every code’s format information so that the sequence never comes out as a long run of all-dark or all-light modules, which the scanner could mistake for ordinary data. After this fixed XOR, the 15 bits are written into reserved strips around the finder patterns, in two physically separated copies: the first surrounds the top-left finder (eight bits running horizontally beneath it and seven bits running vertically to its right), and the second is split across the other two finders (seven bits beside the top-right finder and eight bits beside the bottom-left finder). Both copies are identical, so the scanner can read either one.

What the format information encodes — EC level and mask

The two error-correction-level bits select one of L, M, Q, or H — the four levels covered in depth in our qr error correction deepdive. Once the scanner reads these two bits it knows how many Reed-Solomon codewords to expect and can run the data decoder. The three mask-pattern bits select which of the eight standard masks the encoder applied to the data — the masks explained in our qr code masking guide — so the scanner can regenerate the same mask and XOR it back out before decoding.

These five pieces of information are the entire “how to read this code” header. Nothing else about the decode setup is stored separately: the error-correction level and the mask are both recorded in these 15 bits, and (from version 7 upward) the version is recorded in its own separate version-information block. Until the scanner reads the format information it cannot demask the data or run Reed-Solomon on it, so the format bits are genuinely the first thing decoded after the finders are located.

Why the format information is duplicated — a mini-EC for the metadata

Duplication is the format information’s own error correction. The ten BCH bits already let the scanner recover a few damaged bits within a single copy, but a scratch or smudge running along one finder could obliterate an entire strip. By writing the same 15 bits in two physically separated locations, the standard guarantees that localised damage — a crease, a sticker corner, a splash — almost never takes out both copies at once. The scanner reads whichever copy survives, and if both are partially damaged it can cross-check them.

This is a different kind of resilience from the payload’s Reed-Solomon error correction. The payload can survive losing a percentage of its codewords because the encoder appended redundant check codewords; the format information survives because it is physically replicated. Together they mean a QR tolerates both scattered data damage and localised structural damage — the two failure modes that matter in the real world of printed, handled, weathered codes. Our qr alignment pattern guide covers the other structural marker that shares this “do not restyle” property.

How a scanner reads the format information before the data

The decode order is fixed and deliberate. First the scanner locates the three finder patterns by their 1:1:3:1:1 ratio and fixes position and orientation — covered in our qr finder pattern guide. Then, before it reads a single data module, it samples the format-information strips around the finders, undoes the fixed XOR mask, and runs the BCH check to recover the five data bits. Now it knows the error-correction level and the mask pattern, so it can regenerate the data mask, XOR it out of the data area, and finally run Reed-Solomon decoding on the payload.

The format information is therefore the bridge between “found the code” and “decoded the data.” Without it the scanner has the grid but no idea how to interpret it — which error-correction level to apply or which mask to remove. This is why the format bits must be readable even when the rest of the code is in poor shape: they are the key that unlocks everything else, which is exactly why the standard duplicates them and gives them their own error correction.

The customization trade-off — you cannot restyle the format information

The format information is a structural marker, not a styling surface. Recoloring it independently, breaking its dark/light geometry, or letting a logo or frame overlap the strips around the finders can leave the scanner unable to read the error-correction level and mask — and a code whose format information cannot be decoded cannot be decoded at all, regardless of how much Reed-Solomon redundancy the payload carries. The rule is the same as for the finder, timing, and alignment patterns: keep the structure intact and restyle only the data area.

In practice this means the places to apply brand color and shape are the data modules, the eye shapes (within the 1:1:3:1:1 ratio), and the frame — not the thin reserved strips around the finders. A centered logo stays in the middle of the data area on a level-H code, and any frame sits outside the quiet zone, so neither eats the format-information strips by construction. When in doubt, run the final exported SVG or PNG through a free decoder and confirm the payload round-trips before a print run.

Format information at a glance

The table below summarises the format information so you can see at a glance what it is, what it does, and why it cannot be restyled.

How QRForge handles it

The format information is generated automatically by the encoder for every code, so you never place or style it by hand. The error-correction level you choose in the generator becomes the two level bits; the mask the encoder selects through its penalty-scoring pass becomes the three mask bits; the ten BCH bits and the fixed XOR are computed and placed for you. The same encoder drives the SVG, PNG, and EPS exports, so the format information is identical across all three output formats for the same content.

Because the format information sits in reserved strips around the finders, the styling controls — module and eye shapes, colors, gradients, frames, and the centered logo — are applied to the data area and the eye geometry while the format strips keep their fixed structure by construction. The safe habit is unchanged from our other structural guides: keep the payload short, use level H with a logo, keep the finder eyes and the four-module quiet zone clear, and run the final image through the free decode helper plus a real-phone scan-test before you commit to a print run. See our qr best practices and qr code validation guides for the full checklist.