QR-Code-Datenkapazität: Maximale Zeichen nach Version und Modus

Embed This Widget

Theme


      
    

Widget powered by . Free, no account required.

Capacity is fixed by three variables acting together: version, encoding mode and error correction level. Mode sets the bit cost per character, with numeric packing three digits into 10 bits, alphanumeric two characters into 11, byte mode spending a full 8 bits per character and kanji 13. At the ceiling, a Version 40 symbol holds 7,089 digits, 4,296 alphanumeric characters, 2,953 bytes or 1,817 kanji at correction level L; raising correction to level H reduces those figures to 3,057, 1,852, 1,273 and 784 respectively. Real symbols rarely approach the limit. A short URL of roughly 25 bytes fits inside Version 2.

QR-Code-Datenkapazität: Maximale Zeichen nach Version und Modus

Das Verständnis der QR-Code-Kapazität hilft Ihnen, die richtige Version und Fehlerkorrekturstufe für Ihre Daten zu wählen. Die Kapazität variiert erheblich abhängig von drei Faktoren: Version, Kodierungsmodus und EC-Stufe.

Kapazität nach Kodierungsmodus

QR-Codes unterstützen vier primäre Kodierungsmodi, jeweils mit unterschiedlicher Effizienz:

Modus Zeichen pro Gruppe Bits pro Gruppe Effektive Bits/Zeichen
Numerisch 3 Ziffern 10 Bit 3,33
Alphanumerisch 2 Zeichen 11 Bit 5,5
Byte 1 Byte 8 Bit 8,0
Kanji 1 Zeichen 13 Bit 13,0

Maximale Kapazität (Version 40)

EC-Stufe Numerisch Alphanumerisch Byte Kanji
L (7 %) 7.089 4.296 2.953 1.817
M (15 %) 5.596 3.391 2.331 1.435
Q (25 %) 3.993 2.420 1.663 1.024
H (30 %) 3.057 1.852 1.273 784

Größen typischer Anwendungsfälle

In der Praxis nutzen die meisten QR-Codes nur einen Bruchteil der maximalen Kapazität:

  • Kurz-URL (z. B. https://example.com): ~25 Byte — Version 2, EC-M
  • WiFi-Zugangsdaten: ~50-80 Byte — Version 3-4, EC-M
  • vCard (einfach): ~150-250 Byte — Version 7-10, EC-M
  • vCard (vollständig): ~400-600 Byte — Version 13-18, EC-M
  • Kalenderereignis: ~200-400 Byte — Version 8-14, EC-M

Berechnung der erforderlichen Version

Um die Mindestversion für Ihre Daten zu bestimmen:

  1. Zählen Sie Ihre Datenzeichen und identifizieren Sie den Kodierungsmodus
  2. Fügen Sie den Overhead hinzu: Modusindikator (4 Bit), Zeichenanzahl-Indikator (variiert) und Terminator
  3. Fügen Sie Fehlerkorrektur-Codewörter für Ihre gewählte EC-Stufe hinzu
  4. Finden Sie die kleinste Version mit ausreichender Gesamt-Codewortkapazität

Die meisten Bibliotheken übernehmen dies automatisch, aber eine manuelle Berechnung ist für die Kapazitätsplanung nützlich.

Tipps zur Reduzierung der Datengröße

  • Verwenden Sie URL-Kürzer, um die Linklänge zu reduzieren
  • Großbuchstaben-URLs lösen den alphanumerischen Modus aus (5,5 statt 8 Bit/Zeichen)
  • Verwenden Sie das MeCard-Format statt vCard für kleinere Kontaktcodes
  • Entfernen Sie optionale Felder aus strukturierten Datenformaten

Wichtige Erkenntnisse

  • Version 40 bei EC-L fasst bis zu 7.089 numerische oder 2.953 Byte-Zeichen
  • Höhere Fehlerkorrektur reduziert die verfügbare Kapazität erheblich
  • Die meisten praktischen QR-Codes verwenden die Versionen 2-15
  • Großbuchstaben-URLs sparen im Vergleich zu Kleinbuchstaben etwa 30 %
  • Bibliotheken wählen automatisch die minimale Version für Ihre Daten

Häufig gestellte Fragen

What is the maximum amount of data a QR code can hold?

At Version 40 with correction level L: 7,089 digits, 4,296 alphanumeric characters, 2,953 bytes or 1,817 kanji characters. Raising correction to level H lowers those same ceilings to 3,057, 1,852, 1,273 and 784, because the correction codewords occupy space the data would otherwise use.

Why does the character limit change with the type of data?

Each encoding mode spends a different number of bits per character. Numeric mode packs three digits into 10 bits, alphanumeric two characters into 11, byte mode uses a full 8 bits per character and kanji 13. The same visible length therefore consumes very different amounts of a symbol.

How much of a QR code's capacity does an ordinary URL use?

Very little. A short address of roughly 25 bytes fits inside Version 2, far below any ceiling. Capacity becomes a real constraint mainly for structured payloads: signed credentials, contact records with many fields, or data large enough to need Structured Append across several symbols.