
Hoeveel data kan een QR-code bevatten? De echte limieten
Een QR-code kan tot 2.953 bytes bevatten, maar die grens is een afleiding. Ontdek waarom een lange tracking-URL je code dicht en kwetsbaar maakt, en waarom een korte dynamische redirect bijna altijd beter scant.
ScanKit · Organization
· 14 min. leestijd
Hoeveel data kan een QR-code bevatten?
Een QR-code kan maximaal 7.089 cijfers, 4.296 alfanumerieke tekens of 2.953 bytes aan willekeurige data bevatten. Dat zijn de absolute bovengrenzen, vastgelegd in de ISO/IEC 18004-norm, en ze gelden alleen bij de grootst mogelijke code (versie 40) met het laagste niveau van foutcorrectie. In echte campagnes kom je er nooit in de buurt, en dat moet je ook niet willen. De interessante vraag voor een bureau is niet hoeveel een QR-code kan bevatten, maar hoe weinig hij zou moeten bevatten, want de hoeveelheid data die je codeert bepaalt hoe dicht, hoe kwetsbaar en hoe groot je gedrukte code moet zijn.
Deze gids legt uit waar die getallen vandaan komen, waarom een lange tracking-URL het duurste is wat je in een code kunt stoppen, en waarom de kleinste payload bijna altijd wint. Als je ooit een code hebt afgedrukt die eruitzag als een drukke wirwar van piepkleine blokjes en vervolgens weigerde te scannen vanaf de andere kant van de ruimte, dan is dit de reden.
Het korte antwoord, en de adder onder het gras
Hier zijn de absolute maximumcapaciteiten, ontleend aan Denso Wave (het bedrijf dat de QR-code uitvond) en de ISO/IEC 18004-norm waarop hij gebouwd is. Dit zijn harde specificaties, geen schattingen.
- Numeriek (alleen cijfers): 7.089 tekens
- Alfanumeriek (een beperkte set, zie hieronder): 4.296 tekens
- Byte / binair (willekeurige tekst, en dat is wat URL's gebruiken): 2.953 bytes
- Kanji (Japans dubbel-byte): 1.817 tekens
De adder onder het gras is dat elk van die cijfers uitgaat van versie 40, de grootste code die er is, op foutcorrectieniveau L, het zwakste. Zet je de foutcorrectie hoger, dan zakt de bovengrens snel. In bytemodus daalt het maximum van 2.953 bytes op niveau L naar 1.273 bytes op niveau H, een afname van zo'n 57 procent. Het eerlijke antwoord op "hoeveel data kan een QR-code bevatten" is dus "dat hangt af van de versie en het foutcorrectieniveau", en 2.953 bytes als platte waarheid noemen is een van de meest gemaakte fouten in dit onderwerp.
Het praktische antwoord is nog kleiner. Een gewone weblink is een paar dozijn bytes groot en past in een van de allerkleinste codes die er zijn.
Versies: waarom een QR-code groeit
Een QR-code bestaat in 40 maten, versies genoemd. Versie 1 is een raster van 21 bij 21 modules (een module is een van de kleine zwarte of witte blokjes). Versie 40 is 177 bij 177. Elke stap omhoog voegt vier modules toe aan elke zijde, dus de formule is eenvoudig:
modules per zijde = 21 + 4 x (versie - 1)
Versie 2 is 25 bij 25, versie 5 is 37 bij 37, versie 10 is 57 bij 57, enzovoort tot 177. De encoder kiest de kleinste versie die jouw data kan bevatten op het door jou gekozen foutcorrectieniveau. Meer data dwingt een hogere versie af, en een hogere versie betekent meer modules gepropt in de fysieke ruimte waarin je de code afdrukt. Dat is het hele mechanisme achter een "drukke" code: het is geen ontwerpkeuze, het is je payload die erdoorheen schijnt.
Dit staat los van de fysieke grootte van de gedrukte code, die we behandelen in hoe groot een QR-code moet zijn. Versie gaat over hoeveel blokjes er zijn. Drukgrootte gaat over hoe groot elk blokje uiteindelijk wordt. De twee bepalen samen of een telefoon de code daadwerkelijk kan ontcijferen, en daar komen we nog op terug.
Coderingsmodi: jouw URL is de minst efficiënte soort data
QR-codes slaan tekens niet op zoals een tekstbestand dat doet. De norm definieert vier coderingsmodi, en de encoder kiest automatisch de dichtste die jouw tekens kan weergeven. De modus bepaalt hoeveel bits elk teken kost, en dat is wat de capaciteit echt stuurt.
- Numerieke modus propt drie cijfers in tien bits, ongeveer 3,3 bits per teken. De efficiëntste modus, maar hij kan alleen
0tot9aan. - Alfanumerieke modus propt twee tekens in elf bits, ongeveer 5,5 bits per stuk. De tekenset omvat slechts 45 symbolen: de cijfers, de hoofdletters A tot Z, de spatie en een handvol symbolen (
$ % * + - . / :). Er zijn geen kleine letters en geen van de leestekens waar een URL op leunt. - Bytemodus gebruikt volle acht bits per teken en kan alles weergeven, inclusief kleine letters,
?,=,&,#en_. - Kanji-modus propt Japanse dubbel-byte tekens in dertien bits per stuk.
Hier komt het deel dat ertoe doet voor marketing. Een echte URL zoals https://agency.com/spring?utm_source=poster bevat kleine letters en leestekens uit de querystring, dus hij kan de efficiënte alfanumerieke modus niet gebruiken. Hij zakt terug naar bytemodus met acht bits per teken, de minst dichte tekstoptie die er is. Jouw tracking-link is, byte voor byte, zo ongeveer het duurste wat je een QR-code kunt laten dragen. (Een link in alleen hoofdletters zonder querystring zou in de alfanumerieke modus kunnen passen, maar niemand schrijft URL's zo.)
Foutcorrectie vreet aan het budget
QR-codes kunnen nog steeds gelezen worden als ze bekrast, besmeurd of deels bedekt zijn, omdat ze redundante data meedragen via Reed-Solomon-foutcorrectie. Je kiest zelf hoeveel redundantie je toevoegt, verdeeld over vier niveaus:
- L (Laag): herstelt ongeveer 7 procent van de codewoorden
- M (Medium): ongeveer 15 procent, en de gebruikelijke standaard
- Q (Kwartiel): ongeveer 25 procent
- H (Hoog): ongeveer 30 procent
Die redundantie is niet gratis. Ze neemt hetzelfde databudget in beslag als je payload, dus hoe meer foutcorrectie je toevoegt, hoe minder ruimte er overblijft voor inhoud. Bij versie 40 in bytemodus loopt de capaciteit van 2.953 bytes op L naar 2.331 op M, 1.663 op Q en 1.273 op H. Van L naar H gaan halveert ruimschoots wat je kunt opslaan.
Voor de meeste gedrukte marketingcodes is niveau M een verstandige standaard, en je grijpt pas naar Q of H als je een logo in het midden plaatst of afdrukt op iets dat klappen gaat krijgen. Dat logogeval is een evenwichtsoefening op zich, die we behandelen in hoe je een logo in een QR-code plaatst zonder de scan te breken. Een nuttige precisering: de getallen van 7 tot 30 procent beschrijven het aandeel codewoorden dat de code kan herstellen, niet een gegarandeerd percentage van het fysieke oppervlak dat je mag bedekken. Het is geen vrijbrief om een derde van de code met illustraties te overdekken.

In het diagram hierboven: (1) een korte redirect-URL codeert naar een code met een lage versie, ruim opgezet met grote modules die makkelijk scannen; (2) dezelfde bestemming voluit geschreven met UTM-parameters vraagt een veel hogere versie, dus hetzelfde gedrukte vierkant zit vol met veel kleinere modules; (3) bij dezelfde drukgrootte zijn die kleinere modules moeilijker voor een camera om te ontcijferen, en daar beginnen scans te falen.
Wat dit betekent als je gaat drukken
Het gevolg van dit alles is direct. Meer tekens dwingen een hogere versie af, een hogere versie betekent meer en kleinere modules, en kleinere modules vragen meer resolutie, schonere druk of een fysiek grotere code om leesbaar te blijven.
Neem een concreet, illustratief voorbeeld. Een korte redirect als scn.kit/aB3x9 is zo'n 25 tekens en past in ongeveer een versie 2-code, een raster van 25 bij 25. Schrijf dezelfde campagne voluit, https://agency.com/landing?utm_source=poster&utm_medium=print&utm_campaign=spring25, en je zit op zo'n 120 tekens, wat je naar ongeveer versie 6 of 7 duwt, rond een raster van 45 bij 45. (De exacte versie hangt af van het foutcorrectieniveau en de encoder, dus beschouw dit als illustratief en niet als een vaste regel.) Dat zijn ruwweg drie keer zoveel modules over hetzelfde gedrukte oppervlak, dus elk blokje is nu nog zo'n 40 procent van zijn vroegere breedte. Druk dat op hetzelfde formaat af op een flyer en de kans op falen is veel groter, zeker bij scannen op afstand of onder slecht licht. Een code die niet wil scannen is bijna altijd een van twee dingen: te klein voor zijn dichtheid, of te dicht voor zijn formaat. De overige faaloorzaken diagnosticeren we in waarom scant mijn QR-code niet.
Een gangbare vuistregel voor het formaat is de 10:1-verhouding: de breedte van een code moet ongeveer een tiende zijn van de afstand waarvan hij gescand wordt. Op tien centimeter afstand wil je een code van minstens één centimeter, en een billboard dat vanaf tien meter gelezen wordt wil een code van rond de meter breed. Die regel is brancherichtlijn, geen onderdeel van de ISO-norm, maar het is een betrouwbaar startpunt. Hoe dichter je code, hoe ruimer je met het formaat moet zijn, en dat is het duidelijkste argument om de payload van begin af aan kort te houden.
De oplossing: codeer minder, niet meer
Hier is het structurele probleem met lange URL's in print. Een QR-code is een directe codering van precies de bytes die je hem geeft. Verander één teken en het hele modulepatroon wordt opnieuw berekend en ziet er compleet anders uit. Dat betekent dat je een statische code niet kunt inkorten of bewerken zodra hij gedrukt is: de volledige bestemming zit ingebakken in de stippen op het papier. Als de landingspagina van je klant verhuist, is de code dood.
Dit is de kernreden om een dynamische QR-code te gebruiken. Een statische code codeert de volledige, definitieve bestemming, dus een lange URL met trackingparameters levert een dichte, kwetsbare, grote code op. Een dynamische code codeert alleen een korte redirect, zoiets als scn.kit/aB3x9, en een server vertaalt die korte link naar waar je hem ook op richt. Omdat de gecodeerde string kort is en nooit verandert, blijft het gedrukte patroon laag in versie, ruim opgezet en stabiel, hoe lang de echte bestemming ook is en hoe vaak je hem ook wijzigt. Alle rommelige UTM-parameters leven in de redirect, niet op de illustratie. De volledige afweging tussen beide staat in dynamische versus statische QR-codes, en de praktische werkwijze om een gedrukte code om te leiden staat in de bestemming van een QR-code wijzigen zonder opnieuw te drukken.
Er schuilt een mooie ironie in de marketingclaim dat "dynamische QR-codes meer data bevatten". Ze bevatten juist minder gecodeerde data, slechts een korte link, en precies daarom werken ze beter. De onbeperkte inhoud leeft bij de bestemming, nooit in de code zelf.
Hoeveel heb je eigenlijk nodig?
Voor de overgrote meerderheid van campagnes: heel weinig. Een weblink is een paar dozijn bytes, wat comfortabel past in een code van versie 1 tot 3, het kleine eind van de schaal. Je nadert de hogere versies alleen als je per se een lange URL rechtstreeks wilt coderen, of als je iets echt groots inbouwt zoals een volledig vCard-contact met meerdere velden. Zelfs dan heb je het over honderden bytes, niet duizenden, en lang niet over de bovengrens van 2.953 bytes.
Het juiste mentale model is dus niet "hoeveel kan ik erin proppen". Het is "wat is de kortst mogelijke string die de telefoon brengt waar hij moet zijn". Voor een getrackte marketingcampagne is die string een korte redirect, en al het andere, de bestemming, de tracking, de analytics, zit er veilig achter. Wil je zien wat die redirect je laat meten zodra mensen beginnen te scannen, dan is dat het onderwerp van QR-code-analytics.
Veelgestelde vragen
Hoeveel tekens passen er in een QR-code?
Op het absolute maximum bevat een QR-code 7.089 cijfers, 4.296 alfanumerieke tekens of 2.953 bytes aan algemene tekst. Die cijfers vereisen de grootste code (versie 40) op het laagste foutcorrectieniveau (L). Zet je de foutcorrectie hoger, dan dalen de limieten flink, tot wel 1.273 bytes op niveau H. Codes in de praktijk bevatten veel minder, meestal een paar dozijn tot een paar honderd tekens.
Wat is de maximale URL-lengte voor een QR-code?
Een URL wordt opgeslagen in bytemodus met acht bits per teken, dus de harde bovengrens is 2.953 tekens bij versie 40, niveau L. Dat is puur theoretisch. In de praktijk wil je een URL ruim onder de 100 tekens houden, zodat de code een lage versie blijft en netjes afdrukt. De betrouwbaarste aanpak is een korte redirect van 20 tot 30 tekens te coderen en de lange bestemming erachter te houden.
Wordt een QR-code moeilijker te scannen door een langere URL?
Ja. Een langere URL dwingt een hogere versie af, die meer en kleinere modules in hetzelfde gedrukte oppervlak propt. Kleinere modules vragen meer cameraresolutie, betere drukkwaliteit of een grotere fysieke code om betrouwbaar te lezen. Dit is veruit de meest voorkomende oorzaak van een code die er "druk" uitziet en op afstand niet wil scannen.
Wat zijn QR-code-versies?
Versies zijn de 40 standaardmaten van een QR-code, van versie 1 met 21 bij 21 modules tot versie 40 met 177 bij 177. Elke versie omhoog voegt vier modules per zijde toe. De encoder kiest automatisch de kleinste versie die jouw data bevat op het gekozen foutcorrectieniveau, dus meer data betekent een hogere versie.
Vermindert foutcorrectie de capaciteit van een QR-code?
Ja. Foutcorrectie voegt redundante data toe die hetzelfde budget deelt als je inhoud, dus hogere niveaus laten minder ruimte over. In bytemodus bij versie 40 daalt de capaciteit van 2.953 bytes op niveau L naar 2.331 op M, 1.663 op Q en 1.273 op H. De vier niveaus herstellen respectievelijk ongeveer 7, 15, 25 en 30 procent van de codewoorden.
Kan een QR-code een afbeelding of een hele webpagina opslaan?
Nee. Zelfs op het maximum van 2.953 bytes is er lang niet genoeg ruimte voor een afbeelding of een webpagina. Een QR-code slaat een link naar die inhoud op, niet de inhoud zelf. Daarom verwijst elk praktisch gebruik, van een menu tot een video tot een contactkaart, naar een gehoste bestemming in plaats van het bestand in te bouwen.
Waarom ziet mijn QR-code er zo druk en dicht uit?
Dichtheid is een symptoom van hoeveel data je codeerde. Een lange URL, zeker eentje met UTM-trackingparameters, dwingt een hogere versie af met veel kleine modules, wat zich vertaalt in een drukke, rommelige code. Kort de payload in, idealiter tot een korte redirect, en dezelfde code wordt ruim opgezet en veel makkelijker te scannen.
Bevatten dynamische QR-codes meer data dan statische?
Nee, en de omgekeerde formulering is accurater. Een dynamische code codeert alleen een korte redirect-link, dus hij bevat minder data dan een statische code die een volledige URL draagt. Precies daarom blijft hij klein en scanbaar. De "onbeperkte" inhoud die een dynamische code lijkt te bieden, leeft bij de bestemming, die je op elk moment kunt wijzigen, niet in het gedrukte patroon.
De korte versie
Een QR-code kan technisch gezien tot 2.953 bytes bevatten, maar die bovengrens is een afleiding. De capaciteit daalt bij hogere foutcorrectie, echte URL's worden opgeslagen in de minst efficiënte modus, en elk extra teken duwt de code naar een hogere versie met kleinere, kwetsbaardere modules. De praktische les is het omgekeerde van de gebruikelijke vraag: codeer zo weinig mogelijk. Een korte redirect van een paar dozijn tekens houdt je code ruim opgezet, robuust en makkelijk te scannen, en je kunt de bestemming later wijzigen zonder opnieuw te drukken. Voordat je een code naar de drukker stuurt, kijk naar de lengte van de string die erin zit. Is het een lange tracking-URL, vervang hem dan door een dynamische korte link en laat de redirect het gewicht dragen.
Verder lezen

· 15 min. leestijd
Verlopen QR-codes? Wat een campagne echt laat sneuvelen
Het zwart-witte vierkant verloopt nooit, maar de keten erachter wel: de pagina, het domein, de doorverwijsdienst, het certificaat en de druk. Zo print je een QR-campagne die jaren blijft werken.
Lees meer
· 16 min. leestijd
QR-code drukklaar maken: vector, CMYK en de fout die scans sloopt
Een QR-code die op je scherm scant, kan op de pers mislukken. Leer hoe je een QR-code drukklaar maakt: lever vector aan (of 300 DPI), zet de modules op 100% K in plaats van rich black, bescherm de stille zone en maak een proef op het echte papier.
Lees meer