π³ QR Code Generator
URLs Β· WiFi Β· Contact cards Β· Plain text β no account needed
What Actually Goes Into a QR Code (and Why It Matters When You Generate One)
Most people treat QR codes like magic stickers β point a camera at one and something happens. But if you've ever tried to scan a code that wouldn't cooperate, or wondered why some codes look denser than others, the answer lies in decisions made at generation time. Understanding those decisions helps you produce codes that actually work in the conditions you care about.
The Four Types You'll Use Most
QR codes carry any kind of text, but the way you format that text determines what a scanner does with it. Plain URLs are the simplest case: type https://yoursite.com and every modern smartphone camera app will open a browser on scan. No special formatting required.
WiFi codes follow a specific string pattern: WIFI:T:WPA;S:NetworkName;P:YourPassword;;. Android and iOS both recognise this format and offer to join the network directly, which is genuinely useful for printing on welcome cards in guest rooms or cafes. The double semicolon at the end is not a typo β it's part of the spec.
Contact cards use the vCard format, which looks verbose but encodes cleanly. A minimal vCard starts with BEGIN:VCARD, includes fields like FN (full name), TEL, and EMAIL, and closes with END:VCARD. When someone scans it, their phone prompts them to save a new contact β no typing required on their end.
Plain text is the catch-all. Use it for short SMS drafts, plain instructions, product serial numbers, or anything else that doesn't fit the above templates. Scanners display the raw text, often with an option to search or copy it.
Error Correction: The Setting People Most Often Ignore
Every QR code contains redundant data specifically so that damaged or partially obscured modules can be recovered. There are four error correction levels:
- L (Low, 7%) β smallest code, works fine for clean digital displays
- M (Medium, 15%) β the everyday default, handles minor smudging well
- Q (Quartile, 25%) β good choice for printed materials on uneven surfaces
- H (High, 30%) β survives significant physical damage; use when embedding a logo over the code
Higher correction means more redundant data, which means a physically larger code to store the same content. A short URL at level H might produce a code twice the size of the same URL at level L. On a screen this doesn't matter much. On a business card where you want the code small, it matters a lot.
The practical rule: use M for most things, bump up to Q or H if you're printing on textured paper, fabric, or anywhere the surface might wear. Drop to L only when you need the code as compact as possible and you control the display environment β a clean screen, good lighting, high-contrast background.
Size and Quiet Zone
A QR code's size is expressed in "modules" β the individual dark and light squares that make up the pattern. Version 1 is 21Γ21 modules. Each step up adds 4 modules per side, so version 5 is 37Γ37 and version 10 is 57Γ57. The version chosen automatically depends on how much data you're encoding and which error correction level you've selected.
The quiet zone is the white border surrounding the code. Scanners rely on it to locate the edges of the pattern, and too little quiet space is one of the most common reasons a code fails to scan. The minimum is four modules on each side. When you download a PNG from this generator, those four modules of margin are already baked in. If you're placing the image in a document, avoid cropping it further or running text right up against the edge of the code.
Color Choices That Still Scan
The primary constraint is contrast. Scanners look for the brightness difference between dark and light modules, and they do it in the infrared spectrum as well as visible light. This means some color combinations that look contrasty to the human eye actually fail under certain scanners.
Safe combinations keep the foreground (dark modules) significantly darker than the background. Black on white is obviously reliable. Dark navy on cream works well. Deep green on pale yellow is usually fine. What tends to fail: light blue on white, red on black (both absorb infrared similarly), yellow on white, or any pairing where the foreground and background are close in brightness.
A practical test: convert your color combination to greyscale. If the two values aren't clearly separated β dark grey versus near-white β the code will give scanners trouble.
PNG vs SVG: Which Download Format to Use
PNG is a raster format β the image is stored as a grid of pixels at a fixed resolution. It's universally compatible: paste it into Word, send it in an email, drop it into a slide. The size you choose at generation time determines the pixel dimensions. For most screen use and standard print sizes up to about A5, a "Large" PNG at 8px per module gives clean results.
SVG is a vector format β the code is stored as mathematical shapes that render sharply at any size. This is what you want when the code will be scaled significantly: printed on large banners, embroidered, laser-cut, or placed in an InDesign layout that might export at various sizes. The SVG from this tool opens correctly in Illustrator, Inkscape, and most design applications. It's also smaller in file size for complex codes.
One thing to watch with SVG: some older PDF viewers and email clients don't render SVG images inline. If you're embedding the code in a PDF for general distribution, converting the SVG to a high-resolution PNG first avoids compatibility surprises.
Testing Before You Publish
Generate the code, download it, then scan it with at least two different devices using different apps. The stock camera app on iOS and Android both scan natively. Try also a dedicated scanner app, since they handle lower-contrast codes and unusual sizes differently. If your code is going to print, test a printed copy β not just the screen version β because printer calibration and paper texture both affect scannability in ways that aren't visible until you're holding the physical output.
For WiFi codes specifically, test on the same network the code is meant to unlock. Some devices prompt for confirmation before joining; others connect silently. Either behavior is correct, but knowing which your users will see helps you write accurate instructions alongside the code.
With those steps covered, you'll have a code that works reliably in the conditions that actually matter β not just a code that looks right on screen.