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.