Processed locally
Your input stays in this browser.
A QR code generator turns typed text into a symbol by choosing an encoding mode, an error correction level, and the smallest version that fits the data, then arranging that data into a square grid of modules. ISO/IEC 18004 defines the largest symbol, Version 40 at error correction level L, as holding up to 7,089 numeric digits, 4,296 alphanumeric characters, or 2,953 bytes of binary data.
The first decision: which encoding mode fits the data
ISO/IEC 18004 defines several encoding modes, and a generator's first real job is picking the most efficient one for the exact text it was given. Numeric mode packs three digits into 10 bits and is reserved for digits 0 through 9 only; alphanumeric mode packs two characters into 11 bits and covers uppercase letters, digits, and a fixed set of symbols including space, $, %, and a colon; byte mode spends a full 8 bits per character and covers essentially any text, including lowercase letters, punctuation outside the alphanumeric set, and non-Latin scripts once combined with an extended interpretation code. A fourth mode, Kanji, packs a Shift JIS double-byte character into 13 bits, more efficient than byte mode for that specific character set but irrelevant to a payload with no Japanese text in it at all. A generator that encodes a purely numeric string, such as a phone number, in byte mode rather than numeric mode is not making an error a decoder will reject, but it is wasting capacity that a smaller, denser symbol could have used instead.
Choosing the version and error correction level automatically
A QR symbol comes in 40 defined versions, starting at Version 1, a 21 by 21 module grid, and growing by 4 modules per side up to Version 40, a 177 by 177 module grid, as specified in ISO/IEC 18004. A generator normally works backward from two inputs the person supplies, directly or by default: the data to encode and the desired error correction level, then picks the smallest version among the 40 that can hold that data at that level, since a smaller version means fewer modules and an easier symbol to print and scan at a given physical size. Manually forcing a larger version than the data requires is occasionally useful for a design reason, such as matching a fixed label template, but it otherwise only makes the printed symbol denser and more failure-prone than the data actually demands.
| Mode | Bits per unit | Approximate maximum |
|---|---|---|
| Numeric | 10 bits per 3 digits | 7,089 digits |
| Alphanumeric | 11 bits per 2 characters | 4,296 characters |
| Byte | 8 bits per character | 2,953 bytes |
Worked example: the same idea encoded three different ways
Encoding the ten-digit string 5551234567 in numeric mode needs roughly 34 bits of data capacity before error correction is added; encoding the same ten characters in byte mode needs 80 bits, more than double, purely because byte mode cannot exploit the fact that every character is a digit. A short URL such as example.org/x mixes lowercase letters that fall outside alphanumeric mode's character set, so a generator correctly falls back to byte mode for it even though it contains digits; the same URL typed in uppercase as EXAMPLE.ORG/X could use the denser alphanumeric mode instead, at the cost of a destination that reads oddly to a person. This is why two visually similar payloads, one numeric and one alphanumeric-compatible, can produce a smaller finished symbol than a byte-mode payload of a similar printed length.
What error correction actually adds after the data is arranged
Once the data is arranged, ISO/IEC 18004 layers Reed-Solomon error correction codewords on top of it, at one of four selectable levels: L, M, Q, and H, each reserving progressively more of the symbol's total capacity for recovery data rather than raw content. This is a genuine trade-off a generator's error correction setting controls directly: a higher level such as H can recover a damaged or obscured symbol more successfully, which this site's guide to error correction and logo placement covers in the context of adding a design element, but it also leaves less of the symbol's total capacity for the actual payload at a given version, which can force the generator up to the next larger version for the same input text.
Client-side versus server-side generation
This site builds every QR code inside the visitor's own browser rather than sending the typed content to a server first, which matters for privacy when the payload includes a phone number, an email address, or WiFi credentials that a person would rather not transmit anywhere before the symbol is even created. A server-side generator can still produce an identical, standards-compliant symbol, but it necessarily sees the raw input during that round trip, and a generator built around a dynamic redirect service adds a further layer: the printed QR code encodes a stable short link rather than the final destination, which this site's guide to reading a URL before opening it covers from the scanning side of that same design choice. Neither approach changes the underlying ISO/IEC 18004 mechanics described above; the choice between client-side and server-side generation affects who sees the raw input, not how the finished symbol is structured.
Common generator mistakes that produce an oversized or unreadable code
Pasting an entire paragraph of text into a generator built for a short identifier is the most common mistake, and it produces a needlessly large, high-version symbol with small individual modules that are harder to print and scan reliably at a normal label size; a shortened link or a landing page address is almost always the better payload for anything long. A second mistake is manually forcing a low error correction level to squeeze in more data, then adding a logo or a curved-surface print that actually needed the recovery margin a higher level would have provided. A third is ignoring the quiet zone, the empty margin ISO/IEC 18004 specifies around the symbol, which a generator typically adds automatically but which a layout application can still crop away after export. A fourth, less obvious mistake is regenerating a symbol from a slightly edited payload, such as a corrected phone number, without checking whether the edit pushed the data across a version boundary, since a printed template sized for one version does not necessarily fit the next one up.
What the generator cannot decide for you
ISO/IEC 18004 defines exactly how a compliant symbol is built and read back; it says nothing about whether the destination a person types into the generator is trustworthy, whether a phone camera aimed at the printed result will focus correctly, or whether a particular substrate and printer will reproduce the chosen module size cleanly. A generator's own preview or local decode check confirms the symbol was built correctly from the given input; it does not confirm the finished, physical version will behave the same way, which is why this site's own decode tool exists as an independent second check on the exported file rather than trusting the generator's self-report alone. Treat every version, mode, and error correction choice above as inputs to that later, separate physical proof, not as a substitute for it. ISO/IEC 18004:2024 QR Code specification is the named source for the current external rule or product behaviour.