Text QR Code Generator

Every code on this site has two layers. The payload is the text encoded inside the symbol; the symbol is the matrix of dark and light modules, produced to ISO/IEC 18004 by a vendored copy of the reference encoder (Project Nayuki's qrcodegen). For the other generators the payload follows a convention — a WIFI: string, a vCard, a mailto: URI (RFC 6068) — and that convention is what lets a scanning phone offer to join the network or save the contact. A plain-text code is the one type with no convention at all. The payload is the text you typed, byte for byte: no prefix, no field separators, no escaping. The engine's text builder does exactly one thing before handing the string to the encoder — it refuses an empty box, with the message “Enter some text to encode.” — and everything else passes through unchanged.

That is what makes a text code the right tool wherever the information itself, rather than a web page, is the point:

• Asset and equipment tags: serial number, install date, and service notes on the machine itself, readable by any phone with no app, no database, no connectivity.
• Instructions at the point of need: reset steps taped inside a cabinet, dosing instructions on a container, the "which breaker is which" list inside the panel door.
• Inventory and logistics: box contents that warehouse staff scan instead of reading tiny handwriting.
• Geocaching and puzzles: the classic — a message that reveals itself only to someone who scans.

The symbol layer — how the encoder picks a version, what the error-correction level buys, and why payload mistakes outnumber symbol mistakes — is the subject of the guide How a QR code encodes data. This page stays on the payload, and on reading the facts the engine reports for each example. The tags, notes and numbers on this page are invented; none describe real equipment, places or people.

Reading the symbol facts. The engine encodes that tag as version 5, a symbol 37×37 modules a side, at error-correction level M. The version is chosen by the encoder from the versions the standard defines, numbered 1 to 40 — longer payloads need higher versions — and the module count follows from the version alone, so two payloads that land on the same version produce symbols of the same size however different their text. Error correction is requested at M for every example on this page; the level printed is the one actually encoded, which the reference encoder raises when a higher level fits without increasing the version, and never lowers.

The clearest way to see what the text builder does not do is to run the same string through the builders that do. Punctuation that a payload convention uses as a separator has to be escaped inside that convention. The WIFI: format, per the ZXing Barcode Contents reference the engine follows, reserves \ ; , " : and prefixes each with a backslash; vCard 3.0 (RFC 2426) escapes backslash, semicolon and comma, and writes a line break as the two characters \n. A text payload has no separators, so none of this applies — and nothing has to be undone by the phone that reads it.

The common misreading runs the other way. Because the text builder encodes anything, people paste a web address, a phone number, or even a hand-typed WIFI: string into it and expect the phone to act on it. Sometimes the bytes are identical to what the dedicated generator would have produced — https://example.com/menu is the same payload from either box, and the build checks that it is — but the dedicated builders validate, and some normalise, while the text builder normalises nothing and validates nothing beyond refusing an empty box. The URL builder refuses example.com/menu with “Include the protocol (e.g. https://) so scanners recognize the link.” The text builder accepts it without comment, and without a protocol scanners are not guaranteed to recognise it as a link. The phone builder turns +1 555 013 2000 into tel:+15550132000, a tel: URI (RFC 3966) with the number in E.164 international format; the text builder keeps +1 555 013 2000, spaces and all. If the scanning phone should do something with the content, build it with the generator for that content type: links, phone numbers, contact cards, WiFi.

The text builder hands the encoder the string unchanged, so the only measure of a text payload is its length — and length can be counted two ways. The characters column counts what was typed; the bytes column counts the same text in UTF-8, where the letters, digits and punctuation of ASCII are one byte each and a character outside that range costs more. The table lists every example on this page ordered by payload bytes, with the facts the engine reports for each. Read down it, the version never falls as the byte count rises — the build checks that it does not — and the module count follows the version.

The multilingual label Küche · 厨房 · Cocina ✨ has 21 characters but 30 bytes: every character outside ASCII costs more than one byte of UTF-8, and the label has 6 of them — ü (2 bytes), · (2 bytes each, twice), 厨 (3 bytes), 房 (3 bytes), ✨ (3 bytes). Its 15 ASCII characters account for 15 bytes and the 6 others for 15, which together make the 30. The em dash in the spares note, the boiler tag and the breaker list does the same, which is why those byte counts exceed their character counts; the serial tag and the pump service note, which are pure ASCII, have as many bytes as characters.

Some of the shortest payloads carry an error-correction level above the M that was requested — the serial tag (H) and the multilingual label (Q) — because the encoder found that the higher level fitted in the same version. Nothing is lost by it: error correction is what helps a damaged code scan, and a higher level is more of it.

There is an upper limit, and the engine states it rather than guessing at it: the reference encoder refuses data past the capacity of version 40, and the generator reports the refusal. Stacking 40 copies of the pump service note into the box produces the message “This content is too long for a QR code. Shorten it or lower the error correction level.” Below that limit the practical question is not whether the code can be made but how dense it is — which is a print-size question.

The PNG download offers 3 sizes, and the generator shows a print-size readout for each: it divides the pixel count by a print resolution of 300 DPI to get inches, and converts to millimetres. The readout describes the whole image, quiet zone included. For the service note above, which renders 77 modules across, one module is therefore:

The readout is geometry, not a verdict: it tells you how large each module will be on paper at that resolution, which is the figure print-size questions are really about. A shorter payload at the same pixel size has fewer, larger modules; the long note has more and smaller ones. Three things the renderer settles so that they cannot go wrong by accident:

• The quiet zone is always there. The 4-module light border the standard requires is rendered into every download and cannot be switched off. Cropping it afterwards — trimming the image to the dark modules, or printing the code flush against artwork — is the most common self-inflicted scan failure.
• Contrast is computed, not guessed. The style panel evaluates your colour pair with the WCAG relative-luminance formula and warns below 4.5:1.
• Inverted codes get a warning of their own. Light modules on a dark background are flagged separately, because many scanners reject them. Prefer dark modules on a light background.

Error correction helps a damaged code scan, but print size and contrast still matter. Treat a freshly generated code as untested until a real device has scanned it.

The engine validates format, not truth — and for a text code there is almost no format to validate, so there is almost nothing it can catch. A serial number with two digits transposed encodes as cleanly as the right one. Instructions that were correct when printed stay in the code after the procedure changes. A wrong password typed as plain text encodes without complaint; so does a right one, in the clear, for anyone who scans it. The code is a faithful carrier of whatever you gave it, and the round-trip test suite checks exactly that: each payload type is rendered, rasterised and decoded with an independent decoder, and the decoded text must match the payload byte for byte. What no test can check is whether the words were the right words.

Two properties follow from the data living in the image. Nothing is routed through our servers, so the code cannot expire and cannot be held hostage; and nothing can be changed after printing, so a corrected note means a new code, and scans cannot be counted. Where that trade-off is wrong for you — a document that will be revised — put the content at an address you control and print a link code instead, unless offline access is the whole point.

Read next: How a QR code encodes data — the symbol layer this page only summarises — and the rest of the guides.

If the text you keep encoding is really an address, a phone number, or an email, the dedicated vCard, phone, and email codes trigger the right action on the scanning phone instead of showing plain words.