Processed locally
Your input stays in this browser.
A payload has bytes and encoding modes
QR supports numeric, alphanumeric, byte and other modes. Numeric packs decimal digits more tightly than bytes; alphanumeric covers uppercase letters, digits and a limited punctuation set; UTF-8 text generally requires byte mode. The same visible text can be split into several segments. This tool analyses text before generation, so it can show the mode plan selected by the local encoder rather than guessing modes from a photographed QR image.
Read a mixed example
For `INV-2026-0042 café`, the prefix `INV-2026-0042 ` fits QR alphanumeric mode because its characters are uppercase, digits and hyphen. The accented `café` becomes UTF-8 byte data; its bytes are 63 61 66 C3 A9. Splitting at that boundary avoids encoding the entire identifier as bytes. The table shows each segment, character count and byte values so the saving is visible rather than asserted.
Numeric packing has a formula
Numeric mode packs three digits into 10 bits, two digits into 7 bits and one digit into 4 bits. The sequence `2026` uses 10 bits for `202` and 4 bits for `6`, before its mode and count fields. Encoding those four ASCII digits as bytes would need 32 data bits. Segment headers have a cost, so a short numeric run is not always worth splitting; the local encoder evaluates that trade-off for the chosen QR version.
Alphanumeric is deliberately narrow
The QR alphanumeric alphabet includes `0–9`, `A–Z`, space and `$%*+-./:`. It does not include lowercase letters, an underscore, an accented character or most emoji. A string such as `BOX-42/A` can use alphanumeric mode; `Box-42/A` needs byte mode for the lowercase letters. Changing case just to obtain a smaller code is only valid when that change does not alter the identifier or destination.
UTF-8 bytes are not character count
The letter `é` is one Unicode character but two UTF-8 bytes, C3 A9. An emoji can use four bytes. QR byte-mode capacity and the character-count field count bytes, not the number of glyphs a user sees. That is why a short multilingual sentence can make a denser symbol than an apparently longer ASCII identifier, and why the parser lists bytes explicitly.
What cannot be recovered from a simple camera result
A general QR decoder returns the recovered payload, not necessarily the original segment boundaries chosen by the encoder. `123ABC` could be byte mode throughout or be split under another valid plan. This page therefore analyses entered text with its own generator; it does not claim that a decoded photograph reveals the exact historical encoding choices of an unknown third-party QR image.
Use the result to change a real constraint
If a fixed-size label has marginal module pitch, the segment table can show why a payload became dense: lowercase tracking parameters, a long UTF-8 note, or a contact field that is unnecessary at scan time. Remove only data that is genuinely redundant, then regenerate and check the physical size. Do not treat mode optimisation as a substitute for quiet zone, contrast or proof testing.
A segment trace is not historical evidence
The displayed plan explains how this encoder will represent the text entered here. A recovered payload from an existing symbol does not reveal whether its original producer used the same boundaries, version choice or error-correction setting; several efficient plans can encode identical characters. The trace is useful for planning density, not for making forensic claims about a photographed code.
Read the table as an optimisation trace
The segment list is not a quality score. It documents one valid efficient plan selected by this encoder for its chosen error-correction level and version. A different conforming encoder can choose a different but equally decodable plan, especially where a short numeric run does not repay the extra mode header. Use the trace to explain a specific density change: replacing an uppercase code with mixed case may move a run into byte mode; adding `é` adds two UTF-8 bytes; a longer URL can push the symbol to a larger version. Then test the resulting matrix at the physical dimensions that matter. Bits saved on screen are only useful if they create a measurable print margin.
Keep byte order explicit
The hexadecimal display follows UTF-8 byte order, not a visual glyph order or a scanner-app display convention. For `café`, `C3 A9` is the two-byte encoding of the final character; replacing those bytes with a single Latin-1 value changes the QR byte stream. This matters when an external system expects an exact payload or when a copied string contains an invisible character. The parser makes that discrepancy visible before a label is produced, while the generated QR remains a normal text payload for compatible readers.
Use bytes to find the character a screen hides
A payload that looks like `REF-204` can differ from another by a trailing space, a line feed or a non-breaking space; those changes alter the QR content even though a casual display may look identical. The parser exposes UTF-8 bytes and the encoder's segments so a reviewer can point to the actual difference. For example, ordinary ASCII `A` is one byte 0x41, while an accented character may take more than one UTF-8 byte and may force byte mode. QR Code supports several encoding modes; ISO/IEC 18004:2024 specifies character encoding and symbol formats: https://www.iso.org/standard/83389.html . The parser's value is forensic: it says what the symbol stores, not what an application will decide to do with it.
Compare a source payload with a recovered payload
When a scanned label opens the wrong record, paste the approved source and the recovered value separately, then compare characters, byte counts and visible line endings. If the bytes differ, repair the data source or encoding step. If they match but the host chooses a wrong record, investigate the receiving application's lookup rule. Do not use the parser to visit unfamiliar links, disclose private payloads in a ticket or treat a recognised URI scheme as proof that its destination is safe. For a production proof, retain the source text, parsed output and a scan of the final image. That evidence distinguishes a hidden-character problem from a QR rendering problem and a destination problem. It is especially useful for Wi-Fi, mailto, calendar and contact records, where punctuation can be structure rather than readable prose.
Preserve evidence without exposing private data
When a payload is confidential, run the parser locally and record only the diagnostic facts needed for the incident—for example, byte length, a trailing line feed and the checksum of the source record—rather than pasting credentials or personal fields into a shared ticket. The browser-only tool helps isolate invisible-data faults without turning a troubleshooting note into a second disclosure channel.
Segment changes are not necessarily errors
An encoder may choose numeric, alphanumeric or byte segments according to the characters supplied. A different segmentation can still represent the same bytes, while a single unexpected byte changes the actual payload. Use the parser to compare stored content first; treat mode changes as evidence to inspect, not as a visual failure by themselves.