Per-corner eye styling: three eyes, three looks

Detection does not compare corners

A scanner finds a QR code by locating three candidate finder patterns and checking each one for the 1:1:3:1:1 dark-light ratio through its centre. It never checks whether the three look alike. Orientation comes from their positions (three found, one corner empty), not from their shapes matching. So a code with a rounded top-left eye, a circular top-right and a square bottom-left is, to a decoder, simply three valid finder patterns. Per-corner styling is legitimate, not a hack.

UseQR's core renderer supports this directly: the @useqr/core render options accept per-corner eye overrides (frame style, ball style, frame colour, ball colour for each of the three corners), while the web generator's eye= and ball= parameters apply one style to all three: see custom eye shapes for the five available shapes and their individual risk order.

The rules apply per corner, three times

Nothing about varying the corners relaxes the constraints. It multiplies them. Each eye must independently satisfy:

• A closed, solid dark ring one module thick around a clear light ring around a solid ball, the concentric structure that produces the ratio.
• Full contrast: every frame and ball colour passing the 40-point luminance rule. One fashionably pale eye out of three still sinks detection reliability, because many decoders want all three before committing.
• Sane scale: at small print sizes, the riskier shapes (leaf, diamond) erode first: mixing means your weakest corner sets the code's reliability.

A useful discipline: make the bottom-left eye the most conservative shape when mixing, keep colours within the same dark range, and let one corner carry the flair.

Where per-corner styling actually breaks

The failure is almost never the mixing. It is what people mix in:

• A brand glyph replacing a ball. A logo mark is not a solid 3 × 3 block; its outline breaks the ratio and that corner stops being a finder pattern. If the mark must appear, put it in the centre of the code within the logo budget, following the logo best practices, never in an eye.
• Ornamental frames that open the ring: gaps, notches, sparkle cut-outs.
• Decorating the fourth corner. The bottom-right corner deliberately has no eye; larger codes place alignment patterns in that region. Adding a fake fourth eye or ornament there can both damage alignment data and feed detectors a false candidate.

Because eye validity is binary, verification is trivially reliable: decode the export with the validator. A per-corner design that decodes has three working finder patterns; one that does not will fail every time, not intermittently.

FAQ

Can each QR code eye be a different shape?

Yes. Scanners validate each finder pattern's dark-light ratio independently and use their positions, not their similarity, to orient the code. Any mix of valid solid shapes (square, rounded, circle, leaf, diamond) decodes normally.

Can the three eyes be different colours?

Yes, provided every frame and ball independently keeps at least a 40-point luminance difference against the background. The risk of mixed colours is that the lightest eye becomes the weakest link, so keep all three clearly dark.

Can I put my logo inside a QR code eye?

No. The eye's centre must be a solid dark block for the detection ratio to exist; replacing it with a glyph disables that finder pattern. Place logos in the centre of the code within the error-correction budget instead.

Why is there no eye in the fourth corner?

Three eyes are how the scanner establishes position and orientation: the empty corner is information. Larger codes also carry alignment patterns near that region, so adding decoration there risks both confusing detection and damaging real structure.