COMPACT BIOMETRICS
What actually fits in a QR code once the signature, the metadata and the encoding have taken their share.
A signed QR code carrying a face photograph can form an offline identity credential with no transaction-time database behind it. The signature binds the payload to the holder of a trusted issuing key. The face provides the evidence used to compare the credential with the person presenting it. Verification can work on a phone in a place with no connectivity and no back-end.
The design question is not whether this works. It is how many bytes are left for the face after everything else has been paid for, and whether a face that small is still a face a matcher can use.
Both halves of that question now have published numbers.
The symbol’s capacity, and why it is not the real limit
ISO/IEC 18004 defines forty QR versions. Version 1 is 21 × 21 modules; each version adds four modules per side, so a version V symbol is (4V + 17) modules across. Version 40 is 177 × 177.
At version 40, binary capacity by error-correction level:
| Level | Capacity | Recovery |
|---|---|---|
| L | 2,953 B | ~7% |
| M | 2,331 B | ~15% |
| Q | 1,663 B | ~25% |
| H | 1,273 B | ~30% |
Those are the headline figures. They are also, for a credential printed on a card, unreachable.
The reason is physical. Reliable scanning by a consumer phone camera generally requires a module of roughly 0.3 mm or larger; below that, the limiting factor is the camera’s own optical resolution and the decoder’s tolerance for blur. A version 40 symbol at 0.33 mm modules is 58.4 mm on a side, before the mandatory four-module quiet zone.
An ISO/IEC 7810 ID-1 card is 85.6 × 53.98 mm.
A version 40 QR code, at a module size a phone can reliably read, does not fit on an ID card. It is taller than the card.
Work backwards instead. Allocate 40 mm of card width to the symbol, including the quiet zone, at 0.33 mm modules: 121 modules total, 113 after the quiet zone, which resolves to version 24 at most. The capacity of that symbol is roughly half of the version 40 figure, and it drops again with the error-correction level.
The budget is therefore not “about 3 KB”. It is closer to one kilobyte, and every byte of it is contested.
Where the bytes go before the face gets any
The image is the last item in the accounting, not the first.
The signature. ECDSA on P-256 costs roughly 64 to 72 bytes in DER encoding. A key or certificate identifier adds a few more. It is a compact classical option, but post-quantum transition plans eventually require systems to replace it. ML-DSA-44, the smallest FIPS 204 parameter set, has a 2,420-byte signature, larger than the entire capacity of a version 40 symbol at level H. A post-quantum signature does not fit in this budget at all, which is a design problem worth naming early rather than discovering later.
The metadata. Name, date of birth, document number, expiry, issuing authority, credential type. In a structured container such as an ICAO visible digital seal or a MOSIP claim, this is tens to a couple of hundred bytes depending on field set and encoding.
The serialization. This is the term most often overlooked, and it is large. JSON with base64-encoded binary inflates every byte of image data by one third. NIST’s own worked example encodes a 952-byte WebP image as a base64 string, which occupies roughly 1,270 bytes in the symbol. The additional 318 bytes are pure encoding overhead, a third of the face budget spent on representing binary as text.
CBOR carries binary natively and does not pay this. For a payload dominated by a compressed image, the serialization choice is not a matter of developer preference; it is worth more bytes than most of the metadata.
One trap worth stating. Some QR encoders apply lossless compression to the payload before encoding. Applied to an already-compressed image, this does not shrink anything and can expand it. NIST explicitly recommends disabling it for these payloads.
What remains, after all of that, is approximately one kilobyte. Which brings the question to whether a face survives being that small.
The measurement
NIST Special Publication 500-343, published in September 2025, addresses precisely this. It is the study to start from, and its scale is what makes it useful.
The trial used 465,352 reference mugshots and 1,251,122 verification images, producing 1,251,122 mated comparisons and 93,070,400 non-mated comparisons per preparation method. The pipeline was: detect the face (dlib), crop to a 25% expansion of the bounding box, downsample with anti-aliasing to a target width, then compress iteratively until the encoded file fell at or below a target size.
The parameters swept were target sizes of 600, 800, 960, 1040 and 1200 bytes, and cropped widths of 64, 80, 96, 128 and 160 pixels, across six codecs.
The results, in the order they change decisions:
960 bytes is the threshold. At 960 bytes, recognition error rates approach those obtained with ordinary non-compact passport-style photographs. At 800 bytes, error rates are still detectably elevated. At 600 bytes, they are elevated for every codec and every width. The report’s own guidance is to avoid target sizes at or below 800 bytes.
JPEG is unusable here. JPEG and its JPEG-LI derivative frequently cannot reach these target sizes at all, and when they can, recognition suffers. The report deprecates both for this purpose. WebP produces the lowest error rates, followed by AVIF, HEIC and JPEG 2000. WebP is also substantially faster to encode than AVIF or HEIC.
Downsampling is cheaper than compression. For any given target size, the smallest width tested, 64 pixels, produced the least distributional damage to mated scores. The report suggests a width of 64 pixels, corresponding to an inter-eye distance between roughly 19 and 27 pixels. This is counter-intuitive and it is the single most useful finding for implementers: when the budget is fixed, throw away resolution before you throw away quality.
False matches did not increase in this study. Across the tested algorithms, codecs, sizes and widths, measured false match rates were at or below those for non-compact images. The observed cost was concentrated in the mated distribution and therefore in false non-matches, not in a measured rise in false matches. That distinction should not be generalized beyond the evaluated data and matchers, but it matters when locating the operational risk.
What the compressor struggles with is not the face. The images that failed to compress within budget were good-quality photographs containing high-contrast, high-frequency content near the face: hair, beards, textured clothing, patterned collars. Those details consume bits the face needs. The operational consequence is partly a photography instruction: remove unnecessary high-frequency detail around the face and use an uncluttered background, while keeping capture requirements compatible with the intended biometric process.
A face recognisable to a matcher, at roughly twenty pixels between the eyes, in 960 bytes, with error rates near those of a full passport photograph. The number is small enough to be surprising and it was measured on nearly half a million subjects.
Why not just store a template?
The obvious alternative is to skip the image and store a feature vector. A modern embedding quantised to 8-bit precision fits in a few hundred bytes, smaller than any compressed image and apparently a better use of the budget.
The obstacle is not size. It is interoperability.
Templates are generated and consumed by paired algorithms from a single developer. A template extracted by one vendor’s software is not meaningfully comparable by another’s. A credential built on templates therefore binds the issuing authority to one supplier for the life of the credential, across every verification point, with no migration path that does not require reissuing every document.
The documented exception is fingerprint minutiae under ISO/IEC 39794-2, whose interoperability has been measured across multiple vendors in NIST’s MINEX programme, and whose size is comfortably within QR capacity.
For faces, the image is the interoperable format. It is also human-readable, which matters when automated verification fails and a person has to adjudicate. That is a durable architectural argument, not a temporary one, and it is why the compact-image approach exists at all.
The worksheet
Assembling the above, a defensible budget for a card-mounted credential:
| Item | Bytes |
|---|---|
| Compressed face (WebP, W=64) | 960 |
| Metadata (CBOR) | 100–200 |
| ECDSA P-256 signature + key ID | ~80 |
| Container and framing overhead | 30–60 |
| Total payload | ~1,200–1,300 |
That fits a symbol in the low-to-mid twenties by version, at a module size a phone can read, on a card that meets ID-1 dimensions. It does not fit if the serialization is JSON with base64. It does not fit if the signature is post-quantum. And it does not fit if the error-correction level is chosen without reference to this table. That is the subject of the second part of this series.
Open questions
Several of these are unresolved in the published literature and are tractable for anyone with a test corpus.
- JPEG XL was not evaluated. NIST omitted it for resource reasons, noting prior work showing it outperforming JPEG 2000 down to 2.2 KB. Whether it beats WebP below 1 KB is an open question with a clear experimental design.
- Cropping geometry was not swept. A single crop rule was used throughout. The optimal crop for a fixed byte budget is unstudied.
- Compression profiles tuned for faces. All codecs were run at open-source defaults. A profile that allocates bits toward the periocular region is plausible and untested.
- Widths below 64 pixels. The minimum tested width was also the best-performing one. The floor has not been located.
- Raw capture. The trial compressed images that were already JPEG-compressed, which is operationally realistic but not optimal. How much of the budget is recoverable by compressing from raw is unmeasured.
- Human adjudication. NIST measured machine accuracy, not human accuracy on compact images, and explicitly declines to guess. Whether a 64-pixel or a 160-pixel compact image is easier for a trained reviewer is unknown.
The sixth question is the one with operational consequences, because human review is what happens when the machine says no.
References
- NIST SP 500-343: Preparation of Compact Face Images for 2D Barcodes, Grother, Ngan, Hom (2025)
- ISO/IEC 18004:2024: QR Code bar code symbology specification
- ISO/IEC 7810: Identification cards, physical characteristics
- RFC 8949: Concise Binary Object Representation (CBOR)
- RFC 9649: WebP Image Format
- FIPS 204: Module-Lattice-Based Digital Signature Standard
- ISO/IEC 39794-5: Biometric data interchange formats, face image data
