Put the guidance into practice: open the related free tool. Examples use stated inputs and are not measured performance claims.
| Published capacity example | Version and level | Meaning |
|---|---|---|
| 17 bytes | Version 1, L | Byte-mode capacity |
| 7 bytes | Version 1, H | Less payload room at higher correction |
| 2,953 bytes | Version 40, L | Largest listed standard byte-mode capacity |
| 7,089 digits | Version 40, L | Numeric mode, not arbitrary text |
Capacity belongs to a combination of settings
A QR version defines the grid size. Error correction determines how much room is dedicated to recovery information. Encoding mode determines how the payload is represented. A capacity value without those qualifiers is incomplete.
The standard version sequence runs from 1 through 40. A larger grid can carry more information, but the printed symbol becomes denser if its outside dimensions remain fixed. Capacity and print readability therefore need to be considered together.
Use the complete table when comparing settings. Do not take the largest number in a numeric column and apply it to a URL, contact record or mixed-language text. Those payloads may use different encoding and overhead.
Numeric and alphanumeric modes have restrictions
Numeric mode is efficient for digits. Alphanumeric mode supports a defined restricted set of characters. Byte mode accommodates broader content but may use more capacity for a message that could otherwise fit an efficient restricted mode.
A URL often contains lowercase letters and punctuation beyond the restricted alphanumeric set. A contact record includes structural text, separators and line endings. Its storage requirement is not simply the length of the name shown on the card.
Tidy QR uses UTF-8 byte encoding for predictable mixed-payload handling. It does not promise the largest numeric-mode capacity when the form contains only digits. That implementation choice is documented so the published reference table is not mistaken for a guarantee about every encoder setting.
Visible text and UTF-8 bytes differ
ASCII characters occupy a single byte in UTF-8, while many other characters require more. A short name containing international characters can therefore use a different number of bytes from an equally long ASCII placeholder.
The payload can also contain bytes that are not obvious in a compact preview. Line endings, escaped punctuation and URI query parameters contribute to the encoded content. The final assembled record is the relevant object to measure.
This is why a generator should validate the actual payload and show its selected version. Counting characters in one field cannot account for all the structure added around that field.
A worked encoding example
The illustrative text Cafe contains 4 ASCII characters and 4 UTF-8 bytes. Replacing the final letter with the accented character in Café keeps 4 visible letters but uses 5 UTF-8 bytes. The byte count can be reproduced with the browser's TextEncoder rather than estimated from appearance.
That small example explains the direction of the effect without suggesting that international text should be avoided. Preserve correct names and useful content. If density becomes a problem, remove unnecessary fields or use a stable page rather than stripping meaningful characters.
For a structured contact, measure the entire generated record after escaping and line formatting. A longer field may also trigger line folding in the contact format. The complete payload and the encoder's selected version provide a more accurate basis for print planning.
Error correction changes the available room
DENSO's version 1 byte capacities include 17 bytes at L and 7 at H. The higher correction level dedicates more of the same grid to recovery information. A payload can therefore fit at one level and require a larger version at another.
Adding a logo in Tidy QR selects H, so a design change can affect density even when the original content is unchanged. Inspect the selected version after the final design settings are applied.
Do not interpret that tradeoff as a reason to avoid recovery information entirely. Choose the level appropriate to the format and design, then provide enough physical space. The useful outcome is readable, correct artwork rather than the smallest possible grid at any cost.
A shorter payload can improve practical geometry
Removing unnecessary query parameters or redundant text can reduce the data carried in the symbol. A concise URL on a domain you control can be a useful alternative to a long temporary link. Keep the destination clear and maintainable.
A third-party shortener adds a service dependency, so the smaller payload is not a free improvement in every situation. Decide whether the added redirect is acceptable for the lifetime of the printed material.
For extensive instructions, a page may be more usable than a very large plain-text payload. That changes the offline behavior because the visitor needs access to the page. Make the tradeoff explicit instead of treating every content reduction as purely technical.
Capacity is not a scan-distance specification
A payload fitting in a valid symbol says nothing by itself about a particular phone reading a small print from far away. The module size, material, contrast and camera conditions still matter. A maximal-capacity symbol can be valid and impractical for a tiny label.
Use the actual version and margin in the print calculator. Reserve space for the full square, including the quiet zone. Then test the final material at the intended placement.
When the payload changes, check whether the version changes too. A small content edit near a capacity boundary can move the code to a larger grid. Keeping the old print width without reviewing the new density can invalidate an earlier proof.
Keep the reference and implementation distinct
The capacity table describes the published standard combinations. The product specification describes what this generator chooses to encode and validate. Both are useful, but they answer different questions.
For engineering work that needs an exact encoding strategy, consult the applicable specification and encoder implementation. For ordinary artwork, inspect the generated payload, selected version and physical proof.
The practical lesson is to measure the actual data rather than judge capacity from visible text length. That keeps international content correct and makes print planning more predictable.
Do not count the displayed preview alone
A form may show a friendly summary while the payload includes a URI scheme, separators and escaped fields. Those structural characters are part of the encoded message. Inspect or measure the completed payload rather than the visible label in the form.
For a batch, content lengths can vary enough to select different versions even when every row uses the same design settings. Review the actual generated output and use a representative dense sample for print testing. The capacity reference helps explain the change, while the final module geometry determines what the printer and camera must resolve.
Frequently asked questions
Does a character always use one byte?
No. UTF-8 uses different byte lengths for different characters. Measure the assembled payload.
Why does adding a logo change the version?
The logo workflow selects higher error correction, which can reduce capacity at the previous version.
Can I use the numeric maximum for a URL?
No. The numeric limit applies to numeric mode. A URL or structured record has different encoding requirements.
Sources
Last checked: . Examples are illustrative inputs, not measured results.
- QR Code versions and information capacity, DENSO WAVE. Checked 2026-10-29.
- Capacity table: versions 1 to 10, DENSO WAVE. Checked 2026-10-29.
- Capacity table: versions 31 to 40, DENSO WAVE. Checked 2026-10-29.
- Barcode Contents, ZXing project. Checked 2026-10-29.
- Implementation specifications, checked against source code, Tidy QR. Checked 2026-10-29.