QR Code Encoding Capacity
At maximum size (version 40) and the lowest error correction level, a QR code can hold up to roughly 7,089 numeric digits, 4,296 alphanumeric characters, or 2,953 bytes of binary/text data — but real-world codes for URLs or contact cards use a small fraction of that.
These maximums trade off directly against error correction and print density: pushing more data in means a bigger, more detailed grid, and choosing a higher error correction level (for print reliability) reduces how much data fits at a given version. That's why generators pick the smallest version that fits your content — it keeps the resulting code as simple and scan-friendly as possible.
In practice, a shortened URL might only use a few hundred bytes of that capacity. Long-form content like an entire paragraph of plain text will produce a visibly denser, harder-to-scan-small code — worth keeping in mind before encoding something lengthy.
The three headline numbers (numeric, alphanumeric, byte) aren't interchangeable measures of the same content — they reflect different encoding modes, each suited to a different character set (see the Alphanumeric Mode entry). A URL, which needs lowercase letters, almost always falls into byte mode regardless of length, which is the least space-efficient of the three, meaning a URL uses up capacity faster character-for-character than a pure-numeric string would.
Error correction level is the other major factor competing for that same capacity. At the highest level (H, roughly 30% damage tolerance), a meaningful portion of every version's total capacity is dedicated to redundancy data rather than the actual content, which is why this site's generator — which defaults to level H for print reliability — needs a slightly higher version for the same content than a generator defaulting to a lower error-correction level would.
For virtually every real-world use — a website link, a vCard, a WiFi credential, a short message — actual usage sits well under 1% of the spec's theoretical maximum. The headline numbers matter mainly as a ceiling to be aware of, not a target: the practical goal is almost always encoding the shortest content that accomplishes the job, since shorter content produces a simpler, more reliably scannable code at any given print size.