chevron_leftchevron_right
Input
Each line generates a separate code
QR Code Options
Generated QR Codes (0)
Enter text above to generate QR codes
Generate QR codes and barcodes in bulk from a list, and scan codes out of an image. Covers CODE128, CODE39, EAN-13, EAN-8, UPC and ITF-14 as well as QR.
A QR code stores its data with Reed–Solomon error correction at one of four levels, from L (about 7% of the code recoverable) to H (about 30%). The level is the reason a printed code still scans with a logo over the middle or a coffee ring across a corner, and the reason a code that will be printed small should not use L.
Generation and scanning both run here. The scanner reads from a camera or from an image file and handles the one-dimensional formats too — EAN-13 and UPC-A from retail packaging, Code 128 and Code 39 from logistics labels — where the usual failure is not the code but the photograph: glare across the bars, or a shot taken at an angle that makes the bar widths unreliable.
Capacity is the constraint that decides whether a code is usable. A QR code holds up to about 4,300 alphanumeric characters at the lowest error correction, but the version — the grid size — grows with the payload, so a long URL produces a denser code with smaller modules that needs either a larger print or a closer camera. Shortening a link before encoding it is not cosmetic: it lowers the version, enlarges every module and makes the difference between a code that scans from across a room and one that has to be approached.
The one-dimensional formats are stricter than people expect, and the strictness is the point. EAN-13 and UPC-A carry a fixed number of digits and end in a check digit computed from the others, so an arbitrary string cannot be encoded as one — a rejection is the format refusing to produce something a scanner would read as a different product. Code 128 accepts the full ASCII range and Code 39 a restricted set, which is why logistics labels use the former. Choosing a format is therefore a question about the reader at the other end rather than about appearance.
Scanning failures are usually photographic rather than digital. Glare across a glossy label wipes out the contrast the decoder needs, a photograph taken at an angle makes bar widths unreliable because perspective compresses one side, and a code printed smaller than its module size allows leaves the reader with nothing to lock onto. Error correction recovers a damaged code, not an unreadable image: at level H roughly 30% of the code can be missing and still decode, which is what lets a logo sit in the middle, but no level compensates for a blurred or washed-out photograph.
A QR code does not do anything; it carries text, and the scanner decides what that text means. A string beginning with http:// is offered as a link, one beginning WIFI: is offered as a network to join, and BEGIN:VCARD is offered as a contact — all conventions implemented by the scanning app rather than by the code. The practical consequence is that behaviour differs between phones, and that a code encoding plain text is the most portable thing to print. It also means a code is exactly as trustworthy as wherever it was printed, since nothing about the square reveals the destination before it is read.
No. They are generated in your browser and encode exactly the text you entered. There is no redirect and no analytics.
Most often too little contrast, too small a print size, or no quiet margin. Use pure black on white and test at final size.
Scanning works from an image file — drop it, select it, or paste from the clipboard. Take a photo first, then scan the photo.