QR Code Character Limit: How Much Data Actually Fits

Every QR code has a hard ceiling on how much data it can hold, defined by the ISO/IEC 18004 specification. The number most commonly quoted — 4,296 characters — is real, but it comes with a catch that most articles about QR code limits skip entirely: it only applies to a narrow character set that doesn't include lowercase letters.

Four Encoding Modes, Four Different Ceilings

A QR code doesn't just store "characters" — it picks one of four encoding modes based on what's actually in the data, and each mode has a completely different capacity. Numeric mode handles only the digits 0–9 and is the most space-efficient, packing three digits into 10 bits. Alphanumeric mode adds uppercase letters A–Z, a space, and nine symbols ($ % * + - . / :) — 45 characters total, packed two at a time into 11 bits. Byte mode handles any character in the ISO-8859-1 or UTF-8 set, including lowercase letters, accented characters, and the @ symbol, at a full 8 bits per character. Kanji mode is a separate, more efficient encoding for double-byte Japanese characters.

The mode isn't something a person chooses by hand in most generators — it's selected automatically based on the content. But the mode selected determines which of the four capacity numbers actually applies, and the difference is large: 4,296 alphanumeric characters versus 2,953 bytes is nearly a 32% capacity cut, triggered by nothing more than a single lowercase letter appearing anywhere in the data.

Why Almost No Real-World QR Code Reaches Alphanumeric Mode

This is the detail most character-limit guides for QR codes leave out entirely: alphanumeric mode cannot encode lowercase letters at all. A URL like https://example.com contains lowercase letters and therefore forces byte mode, even though the string is short. The same is true of virtually any email address, any vCard, and any block of normal sentence-case text. Alphanumeric mode is really only reachable for content that's either naturally all-uppercase (like a product serial number) or has been deliberately uppercased before encoding — something most people generating a QR code never think to do, and which makes the resulting text look unusual to a human scanning it.

The 4,296-character figure isn't wrong, but it describes a character set most real content doesn't use. For anything containing a lowercase letter — which includes nearly every URL, email address, and vCard — the number that actually matters is 2,953 bytes, not 4,296 characters.

Error Correction Cuts the Real Number Further

Capacity drops again once error correction is factored in. QR codes use Reed-Solomon error correction, the same family of algorithm used on CDs and DVDs, so the code can still be read even if part of it is damaged, dirty, or partially covered by a logo. Four levels are available, and each one trades capacity for durability:

Most generators default to Level M as a general-purpose balance between reliability and capacity. Moving from L to H — often chosen for codes that will be printed small, placed outdoors, or have a logo overlaid in the center — cuts usable byte-mode capacity by more than half, from 2,953 bytes down to 1,273.

What This Means for a vCard Specifically

A vCard is close to a worst-case scenario for QR capacity, and it's worth spelling out why: names and addresses use lowercase letters, email addresses use lowercase letters and an @ symbol, and most structured fields mix upper and lower case throughout. That means a vCard QR code is virtually always encoded in byte mode, not alphanumeric — so the ceiling to plan around is 2,953 bytes at the most permissive error-correction level, not the 4,296-character figure that gets quoted for QR codes generally. In practice this is rarely a real constraint: a typical vCard with a name, phone number, email, company, and a short note comes in well under 300 bytes, nowhere close to any of these limits. It only becomes relevant if a vCard is padded with a long biography field, multiple physical addresses, or an embedded photo, which push byte count up quickly. For anyone building a vCard for a QR code, Clear vCard generates the .vcf file directly, so the actual byte count of the finished card is known before it's turned into a scannable code.

A Real Point of Confusion: Not Every "Maximum Capacity" Table Online Is Actually the Maximum

It's worth flagging a mistake that shows up across a surprising number of QR code reference pages: tables that present the capacity of a mid-sized version — commonly version 10, a 57×57-module code — as if it were the overall maximum. A version 10 code at Level L holds about 652 numeric digits or 395 alphanumeric characters, and some guides present numbers in roughly that range as "the" QR code limit without mentioning that version 40, the actual largest size in the specification, holds more than ten times as much. Both numbers are accurate for what they measure; the confusion comes from not stating which version is being described. The genuinely maximum figures — 7,089 numeric, 4,296 alphanumeric, 2,953 bytes — only apply at version 40, the largest and least commonly used size.

The Practical Sweet Spot

None of the theoretical maximums are a useful target for a real QR code. A version 40 code is 177×177 modules — dense enough that it needs to be printed several inches wide to remain reliably scannable on an ordinary phone camera, and any data corruption becomes much harder to recover from even at high error-correction levels. Most practical guidance converges on the same rough range: content under roughly 300 characters produces a code that scans quickly and reliably at normal print sizes, whether that's a URL, a short vCard, or a block of contact information. Beyond that, the code gets visibly denser, and print size has to increase to compensate.

---

The honest summary: a QR code's true maximum capacity depends entirely on what's being encoded, not on a single number. Uppercase-only content can reach 4,296 characters; anything with a lowercase letter — which is almost everything, including nearly every vCard — tops out at 2,953 bytes; and error correction reduces both figures further depending on how durable the code needs to be. For nearly all practical use, the real constraint isn't the theoretical ceiling at all — it's staying well under a few hundred characters so the code stays easy to scan.