Hoe groot kan het logo op een QR-code zijn? We hebben het gemeten

"30% foutcorrectie" is geen logobudget. We hebben steeds grotere gaten in codes geslagen op elk EC-niveau totdat een echte decoder het opgaf, en we hebben opgenomen waar het brak.

Max Čelar·31 augustus 2026·Afdrukken & scannen

Wat is hier nieuw: De grootste gecentreerde patch die een QR-code op elk foutcorrectieniveau verdroeg, gemeten door een groeiend gat in een echt symbool te slaan en het met jsQR te decoderen — 4% bij L, 7% bij M, 12% bij Q, 17% bij H — plus twee resultaten die niemand publiceert: verspreide schade breekt een code bij 4% waar één aaneengesloten blob 17% overleeft, en dezelfde patch over een finder pattern breekt het bij 1%.

Elke gids voor het plaatsen van een logo op een QR-code zegt hetzelfde twee dingen: gebruik foutcorrectiëniveau H, en onthoud dat het 30% van de code kan herstellen. Het tweede deel wordt zo vaak herhaald dat het een ontwerptaak is geworden — bedek tot 30% — en dat is niet wat het getal betekent.

We zijn erop afgegaan en hebben gemeten wat het werkelijk betekent.

# Wat “30% foutcorrectie” werkelijk betekent

Een QR-code slaat uw gegevens niet op als pixels die u kunt verliezen. Het slaat codewoorden op: blokken van acht modules, beschermd door Reed-Solomon-foutcorrectie. Het kopfiguurnummer van niveau H beschrijft ruwweg hoeveel van die codewoorden kunnen worden gereconstrueerd — en een deel van die capaciteit wordt verbruikt door de overhead van de codering zelf voordat u iets aanraakt.

Twee gevolgen die belangrijker zijn dan het getal:

• Beschadiging wordt per codewoord geteld, niet per module. Een module verpesten verpest het hele codewoord waartoe het behoort.
• De finder-patronen, timing-patronen en formaatinformatie zijn niet gedekt door foutcorrectie. Ze bepalen hoe de decoder het symbool vindt, en er is niets om ze van te reconstrueren.

Dus “30%” is een feit over de wiskunde en niet een vergunningsbriefje over het plaatje. Hier is het vergunningsbriefje.

# Het gemeten logobudget, per niveau

De methode, zodat u het opnieuw kunt uitvoeren: codeer https://mqr.sh/AB12CD met de encoder die MostlyQR verzend (buildMatrix, wrapping de MIT node-qrcode), vastgezet op symboolversie 3 (29 modules) op elk foutcorrectiëniveau zodat EC de enige variabele is. Render op 8 pixels per module met de volledige 4-module stille zone. Zet een gecentreerd vierkant wit uit, beginnend bij 1% van het symboolgebied en groeiend met 1% tegelijk, en geef de pixels na elke stap aan jsQR 1.4.0. Het geregistreerde getal is de laatste grootte die werd gedecodeerd voordat de eerste fout optrad.

Niveau H is ongeveer vier keer niveau L waard — een echt verschil, en de reden waarom elke gids u vertelt het te gebruiken. Het is ook nergens in de buurt van 30%.

Als vuistregel van deze getallen: op niveau H, een gecentreerd logo dat ongeveer 15% van het codegebied inneemt — een vierkant van ongeveer 39% van de codebreedte — ligt binnen de gemeten limiet met wat speelruimte over. De gemeten limiet op niveau M is 7%, wat een vierkant van ongeveer 26% van de breedte is, dus pas het op dezelfde manier aan en u zit beneden ongeveer een vijfde.

We hebben het hele proces herhaald op 16 pixels per module en kregen identieke resultaten, wat het verwachte resultaat is: dit is een eigenschap van het symbool, niet van de rendering.

# Waarom een blob goedkoper is dan confetti

Hier is het resultaat dat we niet verwachtten, en het is degene die uitlegt waarom gecentreerde logo’s überhaupt werken.

In plaats van één aaneengesloten patch schakelden we individuele datamodules willekeurig uit over het symbool — laten elke finder-, timing- en alignmentpatroon onaangetast — en verhoogden het tempo totdat decodering mislukte. Dezelfde payload, dezelfde versie, dezelfde decoder, vijf verschillende willekeurige seeds:

(Het v3-symbool heeft 841 modules, waarvan 567 gegevens dragen; de rest zijn finder-, timing-, alignments- en formaatpatronen, die deze test intact liet.)

Vier procent verspreid, tegen zeventien procent in één blob, op hetzelfde niveau.

De reden is het codewoord. Een aaneengesloten vierkant van 17% vernietigt een klein aantal codewoorden volledig. Dezelfde hoeveelheid schade verspreid over veel codewoorden — en een codewoord met één slecht module is precies zo kapot als een codewoord met acht. Foutcorrectie telt slachtoffers, niet schade.

Wat het gebruikelijke instinct omkeert. Een enkele schone vorm op één plaats is de goedkoopste manier om uw foutcorrectie uit te geven. Spikkelen, een textuur, een half-transparant watermerk of een fotofilter over de hele code is het duurst, zelfs wanneer het er als minder schade uitziet.

# De drie hoeken die u niet mag bedekken

Dezelfde test, dezelfde groeiende vierkant, verplaatst naar twee andere posities:

Op niveau L mislukte het geval van de bovenste-linkse hoek al bij de allereerste stap — onder 1%.

Die hoeken zijn structuur, geen inhoud. De drie grote concentrische vierkanten zijn de finderpatronen, en de kleinere ingebed in de buurt van de onderste-rechtse hoek is een alignmentpatroon; ertussenin bepaalt de decoder waar het symbool zich bevindt, hoe groot het is en hoe het is geroteerd of scheefgetrokken. Bedek er een en er is geen decoderingsstap om te bereiken. Foutcorrectiëniveau maakt bijna geen verschil, omdat foutcorrectie hen nooit beschermde.

Dit is waarom de veilige plaats voor een logo het midden is, en waarom “maak het gewoon kleiner en leg het in een hoek” precies andersom is.

# Wat een camera toevoegt dat deze test niet doet

Alles hierboven is een schoon, synthetisch, best case:

• Één decoder. jsQR is een goede, veel gebruikte decoder, maar de camerastapel van een telefoon is niet jsQR. Echte lezers verschillen in hoe agressief ze een beschadigde code proberen.
• Perfecte pixels. Geen onscherpte, geen schittering, geen perspectief, geen afdruk. Elk daarvan verlaagt het budget.
• Een schoon wit gat. Een echt logo heeft kleur, randen en antialiasing tegen de modules eronder. De witte plaat achter een logo is niet decoratie — het is wat het bedekte gebied ondubbelzinnig maakt.

Behandel de tabel als een bovengrens gemeten onder ideale omstandigheden, niet als een doel om naartoe te ontwerpen. Ons eigen advies is om ongeveer twee-derde ervan uit te geven.

# Dit zelf opnieuw uitvoeren

Elk getal hierboven wordt afgedrukt door een script in plaats van getypt in het artikel: draft/mostlyqr/seo/benchmarks/logo.js in onze repository. Het rendert het symbool op elk niveau, groeit elke patch een procent tegelijk, voert de verspreide-schade vergelijking uit over vijf seeds, en voert het hele ding opnieuw uit op een tweede pixelschaal. Het onderzoekt ook onze eigen validator voor de grens geciteerd aan het einde van dit artikel.

# Wat u werkelijk moet doen

1. Gebruik foutcorrectiëniveau H wanneer er een logo is. Het verviervoudigt ruwweg uw budget, en het kost ongeveer vier extra modules per zijde op een korte link — wat een formaatbeslissing is die u kunt berekenen in plaats van te raden.
2. Houd het logo gecentreerd, en houd het onder ongeveer 15% van het codegebied. Dat is een vierkant van ongeveer 39% van de codebreedte, op niveau H.
3. Zet het op een solide plaat, zodat het bedekte gebied schoon is in plaats van dubbelzinnig.
4. Zorg ervoor dat niets de drie hoekvierkanten aanraakt — niet het logo, niet een frame, niet een afronding van de hoeken.
5. Test de werkelijke afdruk met een slecht telefoontje. Elk getal hier zegt welke ontwerpen het waard zijn om te testen. Alleen de test zegt of het werkt.

Als u wilt dat de afbeelding de hele code is in plaats van een patch in het midden ervan, dat is een ander techniek met een ander budget — we hebben foto-QR-codes afzonderlijk gemeten, en het blijkt dat ze helemaal geen foutcorrectie gebruiken. En als u gewoon een code met uw logo erop wilt, MostlyQR’s generator dwingt foutcorrectie af tot niveau H op het moment dat een logo wordt toegevoegd, behoudt de 4-module stille zone, en stelt het logo standaard in op 22% van de codebreedte — 4,8% van het gebied, comfortabel binnen alles wat hierboven is gemeten.

Één eerlijk opmerking over onze eigen code, omdat we de getallen publiceren: de bewaker die een oversized logo weigert gebruikt het nominale 30% herstelcijfer met een 15% haaruitsnijding, dus het zal een logo accepteren dat ongeveer 25% van het gebied bedekt op niveau H. Onze meting zegt dat het echte plafond dichter bij 17% ligt. De standaard die niemand verandert is veilig met een ruime marge, maar de limiet is losser dan het bewijs ondersteunt, en dat is een bug in onze validator in plaats van een subtiliteit van QR-codes, en het staat op de reparatielijst.