QR Code Generator

Generate a QR code that actually scans — URL, WiFi, email, SMS, phone or plain text

Pick a content type, type the payload, and the code redraws as you type. There is no "generate" button to hunt for and no account step. Everything runs in your browser using a JavaScript QR encoder, so the URL you are encoding, the WiFi password you are handing to guests and the phone number you are putting on a flyer never leave the machine you are sitting at. Nothing is uploaded, nothing is logged server-side, and the generated code is not stored anywhere for later retrieval — if you close the tab before downloading, it is gone.

When you are done, download the result as a PNG for slides and social posts, or as an SVG when the code is going to print and needs to stay crisp at any size. For URL and plain-text codes you can also copy a shareable link that reopens this page with the same payload, size and error-correction level already filled in — useful when you are handing the job to a designer.

The six content types, and what each one actually encodes

A QR code has no concept of "a WiFi code" or "an email code". It encodes a string. What makes a scan open the mail app instead of a browser is the prefix convention the string uses, which phone cameras recognise. This tool builds those strings for you:

Two honest caveats. First, this tool does not build vCard or MeCard contact codes — if you need a full contact card with name, title, company and address, this is not the right generator. Use the Email or Phone type for a single point of contact instead. Second, the shareable-link feature only round-trips the URL and Text types; the structured types (email, phone, SMS, WiFi) are deliberately not written into the query string, which is exactly what you want for a WiFi password.

The WiFi code is a plaintext password on a wall

Worth being blunt about: a WiFi QR code contains the network password in readable plain text. Anyone who photographs the poster can decode it with any QR reader. That is fine for a guest or café network, and it is a genuinely good use of the format. It is not fine for the network your point-of-sale terminals and file server sit on. If you are printing a guest code, print a guest network. The encryption dropdown offers WPA/WPA2, WEP and None; pick the one the access point is actually running, because a mismatch makes the join attempt fail silently on some phones. Choose "None" only for genuinely open networks — the password field is ignored in that case.

Error correction: how much damage the code can survive

QR codes carry Reed–Solomon error correction, which means a portion of the code can be obscured, smudged or torn and a reader can still reconstruct the payload. You choose how much of that redundancy to spend. The four levels defined by the QR standard are:

The tradeoff is direct and unavoidable: redundancy costs capacity. At a fixed amount of data, raising the level from L to H forces the encoder to use a larger QR version — more modules, each one smaller on the page at the same physical dimensions. So the level that makes the code more robust in theory can make it harder to scan in practice, because you have shrunk every module. The rule of thumb that works: choose the level by how the code will be handled, then check the printed size is still generous, and raise the size rather than lowering the level.

How much data fits

The QR standard tops out at version 40, which holds up to 7,089 numeric characters, 4,296 alphanumeric characters, or 2,953 bytes — and those maxima are only available at error correction level L. Higher levels reduce them substantially. Those are ceilings, not targets. A code near the ceiling has a very fine module grid and will frustrate a mid-range phone camera in poor light. In practice, keep URL payloads short. If your link is a tracking URL with fifteen query parameters, shorten it before encoding — the difference between a 40-character URL and a 200-character one is visible to the naked eye in the density of the resulting code.

Size, margin and the quiet zone

The size slider runs from 256 to 1024 pixels in 128-pixel steps and controls the exported raster dimensions, not the number of modules. The module count is decided by your payload length and error correction level; the size setting just decides how many pixels each module gets. Bigger export means more pixels per module, which means more tolerance for camera blur, cheap optics and awkward angles.

The generator renders a two-module margin around the code. That margin is the quiet zone — blank space a reader needs in order to find the code’s boundary at all. The QR specification calls for a quiet zone of four modules, so if your code is going somewhere crowded, place it on additional white space rather than butting it up against artwork, a table border or the edge of the page. This is one of the most common reasons a technically perfect code fails to scan on a busy layout.

Print size in the physical world

Pixels stop being meaningful once the code is on paper; what matters is millimetres per module and reading distance. Download the SVG for anything going to print — it scales without the soft, fuzzy module edges that a scaled-up PNG produces, and fuzzy edges are exactly what defeats a scanner. A widely used starting point for handheld distances is a code no smaller than about 2 cm square, scaled up for longer reading distances: a code on a window intended to be scanned from the pavement needs to be dramatically larger than one on a business card.

Contrast and colour

The foreground and background colour pickers let you match a brand palette, and this is where most homemade QR codes go wrong. A scanner thresholds the image into dark and light modules. It needs the "dark" modules to be genuinely darker than the "light" ones under real lighting, through a phone camera that is auto-exposing for the whole scene.

• Keep the dark modules dark. A pastel or mid-tone foreground on white is the single most common failure. Black on white is not a lack of imagination; it is the highest-contrast option available.
• Do not invert. Light modules on a dark background — white on navy, for example — is rejected outright by some readers, which assume dark-on-light. If you must, test on several phones, not just yours.
• Avoid low-contrast pairs such as dark blue on black or yellow on white. If a colour pair would fail a WCAG contrast check for text, treat it as unusable for a QR code too.
• Watch the print stock. Colours that separate cleanly on a backlit monitor can converge on uncoated matte paper, and a glossy stock adds specular glare that washes out the difference further.
• The background must be opaque. Exports here use a solid background colour, not transparency, which is what you want — a transparent PNG dropped onto a photograph produces an unreadable code.

Failure modes worth knowing before you print 5,000 of them

• Too much data in too small a code. The most frequent real-world failure. A long URL at high error correction printed at 1.5 cm is a wall of near-invisible speckle. Shorten the payload, or enlarge the print.
• No quiet zone. The code is fine; the reader cannot find its edges. Give it surrounding white space.
• Scaling a PNG up in a layout tool. Interpolation blurs module boundaries. Export the SVG and scale that instead.
• A logo dropped in the middle. This works only because error correction covers for the destroyed modules. If you are going to do it, use level H, keep the overlay small, and test the printed proof — not the on-screen mockup.
• An untested URL. Scan the code before it goes anywhere. A typo in the domain, a missing https://, or a staging URL that will 404 in production are all invisible in the black-and-white pattern.
• Printing over a fold or a seam. A code that straddles the fold of a leaflet or wraps a curved bottle will not lie flat under a camera.

A QR code cannot be edited once it is printed

This is the point most people learn the expensive way. The URL is baked into the pattern of black and white modules. There is no server in the middle, no lookup, no dashboard. Reprinting the banner is the only way to change where a printed code goes.

The standard defence is one layer of indirection: encode a URL you control and can redirect later — something like https://yourdomain.com/go/spring on your own domain, configured to redirect to wherever the campaign currently lives. Then the printed code stays valid forever and the destination is a configuration change. The tradeoff is that a redirect URL is slightly longer than a bare landing-page path, and that you must keep that redirect alive for as long as the printed material exists. Third-party "dynamic QR" services do exactly this, with the significant catch that the code dies if the service does or if you stop paying. Codes generated here are static by design: they point wherever you told them to, they depend on no service of ours, and they will keep working long after this page does.

Testing before you commit

Scan the actual output, at the actual size, on the actual medium, with more than one phone. A code that scans instantly from a laptop screen at 800 pixels can fail at 18 mm on matte card in a dim restaurant. Test at an angle, test in low light, and test with an older handset if your audience is likely to have one. Note that this generator creates codes; it does not read or decode them, so use a phone camera or a dedicated reader for verification.