This page is a practical reference for the parts of the QR specification that actually matter when you generate a code. It covers error correction levels and the Reed–Solomon mathematics behind them, the output formats NoTraQR offers (PNG, SVG, STL) and when to use which, and a direct comparison with traditional 1D barcodes. It assumes you already know roughly what a QR code looks like; if you want the historical and structural background first, the history and anatomy page covers that.
Error correction levels: L, M, Q and H
Every QR code carries redundant data so that a damaged, dirty or partially obscured pattern can still be decoded correctly. The amount of redundancy is set when the code is generated, by choosing one of four error correction levels defined in ISO/IEC 18004:
| Level | Recovery | Typical use |
|---|---|---|
| L (Low) | ~7% | Clean digital displays, screens, well-protected print. |
| M (Medium) | ~15% | Default for most printed materials. A good balance of size and resilience. |
| Q (Quartile) | ~25% | Outdoor signage, labels in dirty or industrial environments. |
| H (High) | ~30% | Mandatory if you place a logo over the centre, or for surfaces likely to be scratched, faded or worn. |
The percentage refers to how many of the data codewords can be lost or corrupted before the payload becomes unrecoverable. Higher levels produce physically larger codes — at level H, almost a third of the modules are dedicated to recovery — so you trade real estate for resilience. For a typical URL on a poster, M is appropriate. For a sticker on a metal pipe in a workshop, choose Q or H.
Reed–Solomon, in plain terms
The mathematics that makes this redundancy possible is Reed–Solomon coding, the same family of error-correcting codes used on CDs, DVDs and in deep-space communications. The intuition, without the algebra, is this: the encoder treats your data plus extra "check" bytes as the values of a polynomial sampled at known points. As long as you can read enough of those samples cleanly, you can reconstruct the original polynomial — and therefore the data — even if some samples are missing or wrong.
The QR specification splits the codewords into blocks, applies Reed–Solomon to each block, then interleaves them across the grid. This means damage that affects a localised area of the code (a coffee stain, a scratch, a stuck-on price label) is spread across multiple blocks and is much more likely to be recoverable. For the underlying mathematics, the Wikipedia article on Reed–Solomon is a thorough starting point.
When to overshoot
Two situations almost always justify level H regardless of what else you are doing:
- Logo overlay. Placing a logo over the centre covers data modules. Level H ensures the scanner can recover the code from the remaining 70%+ that is still visible.
- Permanent installation. A QR code on a building plaque, on outdoor signage, on a product that lives in a workshop or warehouse — anywhere the code may slowly accumulate damage over years — should be H from day one. Reprinting is more expensive than a slightly larger code.
Output formats: PNG, SVG and STL
NoTraQR can deliver a generated QR code in three formats. They are not interchangeable — each has a use case where it is the right answer and others where it is the wrong one.
PNG — for screens and quick reuse
PNG is a lossless raster (bitmap) format. It contains a fixed grid of pixels at a chosen resolution, typically 200, 300 or 400 px in NoTraQR. PNG is the right choice when the QR code is going to be displayed on a screen at roughly its generated size — embedded in an email signature, a slide deck, a social-media post, a digital sign or a receipt. It is also the most universally supported format: every operating system, image viewer and CMS handles PNG without help.
The trade-off is that PNG does not scale up cleanly. A 300 × 300 PNG enlarged to 10 cm in print will look soft and pixellated, because the printer has to invent the missing pixels. For anything that will be printed larger than the original generation size, prefer SVG.
SVG — for print, signage and infinite scaling
SVG is a vector format: it stores the code as geometric shapes (squares, paths) rather than as a fixed pixel grid. The result can be enlarged from a business card to a billboard without any loss of quality, because the renderer redraws the shapes at the requested size every time. SVG is the right choice for any kind of print job — flyers, posters, packaging, banners, decals — and for assets handed to a designer who will composite the code into a larger layout.
SVG is also the most space-efficient format for QR codes: a typical QR SVG is a few kilobytes regardless of intended print size. Most modern design tools (Illustrator, Affinity Designer, Inkscape, Figma) import SVG natively. If a tool insists on a raster, it is usually safer to import the SVG and re-export at the required resolution than to start from a small PNG.
STL — for 3D printing
STL is the standard file format for 3D-printable models. NoTraQR is one of the few generators that exports a QR code directly as a 3D mesh: a flat baseplate with the dark modules raised by a configurable height, ready to slice in Bambu Studio, Cura or PrusaSlicer. Typical applications are decorative plaques, workshop labels, asset tags, keyrings, restaurant menu stands and signage.
Two practical recommendations for STL output: always use error correction level H, because dust and scratches on a printed surface degrade scan quality faster than on paper; and print in two contrasting colours. A dark module on a light base — either via a filament change at the modules layer, or with a multi-material system like the Bambu AMS — reads vastly more reliably than a single-colour relief print under typical lighting.
Practical print and display sizing
The minimum size at which a QR code will reliably scan depends on three things: how much data it encodes (which sets the version, and therefore the number of modules), the camera quality of the scanning device, and the distance from which it will be scanned. As rules of thumb that hold across most consumer scanning hardware:
- 2 cm × 2 cm is a safe minimum for a short URL on printed paper held at arm's length.
- 3 cm × 3 cm is more comfortable for codes carrying a vCard, longer URL or WiFi credentials.
- For a code expected to be scanned from distance D, a useful guideline is to make it at least D / 10 in width — a billboard scanned from 5 m needs to be at least 50 cm wide.
- Always leave a quiet zone of at least four modules of empty space around the code. Scanners use this margin to detect the boundary of the pattern; designs that crop the quiet zone away routinely fail to scan.
- Maintain high contrast between modules and background. Black on white is the most reliable combination; if you must use brand colours, keep the foreground much darker than the background and test both on screen and on a printed proof before committing.
Always test a finished code on at least two devices — ideally one iOS and one Android — before sending a print job to production. The cost of a reprint is much higher than the cost of a thirty-second scan test.
Keeping the payload small
Module count grows with payload size, and denser codes scan less reliably at small sizes. Two practical habits help. First, keep URLs short: a 30-character URL produces a noticeably smaller code than a 200-character one with tracking parameters. If a long URL cannot be avoided, route it through a short link first. Second, when generating a vCard, include only fields you actually need. Adding a long postal address, a fax number, a second email and a multi-line "note" field can push a vCard from a comfortable Version 6 code to a Version 15 code that is twice as wide and considerably harder to scan from a business-card-sized print.
Special characters in WiFi passwords deserve their own warning. Quotation marks, backslashes and semicolons have meaning in the WiFi QR specification and need to be escaped. NoTraQR handles this for you, but the safe practice is to scan the generated code with both an iOS and an Android device immediately after generation to confirm the resulting password matches what you typed.
QR codes versus traditional 1D barcodes
The familiar zebra-stripe barcodes on supermarket products — UPC and EAN, with their close cousins Code 128 and Code 39 — are one-dimensional codes. The information is encoded only along the horizontal axis; the vertical bars are simply repeated to make the code easier to scan with a sweeping laser. QR codes are two-dimensional: information is encoded across both axes, which is why their capacity is so dramatically higher.
| Property | 1D barcode (e.g. EAN-13) | QR code (Version 40, level L) |
|---|---|---|
| Maximum numeric capacity | ~13 digits | ~7,089 digits |
| Maximum byte capacity | ~20 characters (Code 128) | ~2,953 bytes |
| Reading direction | Horizontal sweep only | Any orientation |
| Built-in error correction | Minimal | Up to ~30% recoverable |
| Native to consumer phones | Requires barcode app | Built into iOS and Android camera |
| Designed for | Retail point of sale | General-purpose data exchange |
The practical consequence is that QR codes can carry an entire vCard, a WiFi credential pair, a payment URL or a multilingual product manual link — uses that are physically impossible with a 1D barcode. Conversely, 1D barcodes remain perfectly fine for what they were designed for: identifying products at supermarket checkouts using inexpensive laser scanners.
Compliance and the standard
NoTraQR generates codes that conform to ISO/IEC 18004:2015. Every standard QR scanner — including the camera apps built into iOS and Android, and dedicated industrial readers — will decode the output without special configuration. Because the encoder runs in your browser as JavaScript, the entire generation pipeline is verifiable and repeatable: the same input always produces the same code, regardless of the device or the time of day. For background on why this matters from a privacy perspective, see why no tracking.