Free QR Code Generator

Each of the dedicated generators has its own page with a preconfigured generator, a worked example produced by the same engine, and format-specific printing guidance:

A QR code has two independent layers, and keeping them apart explains most of what happens on this site. The payload is the text encoded inside the code — a URL, a WIFI: string, a vCard, a tel: number. The symbol is the black-and-white matrix that carries that text, produced to the QR standard (ISO/IEC 18004) with error correction built in. The generator above builds the payload for each of the 10 content types to a documented convention, then hands the finished text to a vendored copy of the reference encoder (Project Nayuki's qrcodegen), kept byte-comparable with upstream, which chooses the smallest symbol that holds it.

The split matters because the two layers fail differently. The symbol layer is the same for every content type — the encoder does not know or care whether the text it was handed is a link or a password — so a symbol problem looks the same everywhere: a cropped quiet zone, inverted colours, a logo that covers too much. A payload problem is specific to its convention: a WIFI: string with an unescaped semicolon, a phone number without its country code, a URL without its protocol. Most "my code doesn't work" problems are payload problems, which is why each dedicated page spends most of its words on exactly what its builder writes, and why the engine's tests check every builder against independently constructed reference strings, including hostile inputs such as passwords full of semicolons.

Every worked example on this site ends with the same three facts, read back from the encoder rather than typed into the page. The version is the size class the encoder chose, from 1 to 40. The module count is the symbol's width and height in modules — the small squares — not counting the quiet zone; the engine documents it as 17 + 4 × version, both figures derived here from two of the examples below, and this page checks every example against that rule when it is built. The error-correction level is one of L, M, Q or H, as the engine exposes them. The generator encodes at M unless you choose otherwise, and the level reported is the one actually encoded: never lower than requested, sometimes higher, because the reference encoder raises the level when doing so does not increase the version. A logo overrides the choice and forces H.

The table collects the facts for one engine-built payload of each single-line convention plus a contact card, all on fictional inputs, ordered by payload length. Read down it and the mechanism is visible: the content type does not set the version, the payload length does. The shortest payload — the phone call, 17 characters — is version 2 at 25×25 modules; the longest — the contact card, 159 characters across 8 lines — needs version 9 at 53×53.

The print-size readout in the download panel is arithmetic on top of these facts, not a scanning guarantee. A PNG download is a square of 512, 1024, 2048 pixels, and the readout divides the pixel width by 300 to give inches, then converts to millimetres. The image divides that width among the symbol's modules plus the 4-module quiet zone on each side, so the same preset prints a short payload with wider modules than a long one. The table shows the module width that falls out of that division for the shortest and longest examples above.

Error correction helps a damaged code scan, but print size and contrast still matter, and the engine cannot know what your printer and your readers' cameras will make of a given module width. Treat a freshly generated code as untested until a real device has scanned it. The SVG download is the same symbol as a single vector path, quiet zone included, and scales without pixelation.

• Quiet zone, always. The standard requires a 4-module white border on every side of the symbol. The renderer draws it into every PNG and SVG download and offers no way to disable it, because cropping it is the most common self-inflicted scan failure. In the worked example above, the symbol is 29 of the 37 modules across; the rest is quiet zone, and it must stay white.
• Logo overlays force error correction H. A centre logo destroys modules that error correction must rebuild, so whenever a logo is present the engine encodes at the highest recovery level and caps the logo at 16% of the symbol area, with the default overlay held at 12% so real-world prints keep decode headroom. The cap is decode-tested — the round-trip suite verifies that a worst-case logo at that size still scans — not derived from the theoretical ~30% EC-H recovery ceiling. The logo is part of the image, never part of the payload.
• Contrast is computed, not guessed. The style panel evaluates your colour pair with the WCAG relative-luminance contrast formula and warns below 4.5:1, and warns separately for light-on-dark (inverted) codes, which many scanners reject. Black on white assesses at 21.00:1 with no warnings. Mid-grey modules on white (#9a9a9a on #ffffff) assess at 2.81:1, and the panel reports: "Low contrast (2.81:1). Scanners may fail below 4.5:1 — darken the foreground or lighten the background." White modules on a near-black background (#ffffff on #1a1a1a) assess at 17.40:1 — well above the threshold — and the engine still warns: "Light-on-dark (inverted) codes are not reliably read by all scanners. Prefer dark modules on a light background." Contrast is necessary; it is not sufficient.

Three guides take each rule further: Error correction and logos, The quiet zone and print size and Contrast and inverted codes.

Each content type is written to a documented convention, and the builder's header names its source; the sources were verified against the live documents on 2026-07-20. The ZXing "Barcode Contents" reference covers the de-facto formats — the URL, WiFi, contact, calendar and location conventions — and the URI schemes are RFCs. The payloads in the table were built by those builders when this page was built, on fictional inputs: the reserved documentation domains, a number from a range reserved for fiction, an invented network and an invented bindery.

A few of the rules are worth knowing before you fill in the form, because each is a place where a payload that looks right is wrong:

• Links are encoded exactly as entered after validation. The protocol must be present so scanners recognize the text as a URL, and only http and https are accepted. The URL is never wrapped in a shortener or tracking redirect — the payload in the worked example is the address itself.
• WiFi uses the de-facto WIFI:T:<auth>;S:<ssid>;P:<password>;; convention, with the special characters \ ; , : " backslash-escaped so punctuation in a password cannot corrupt the code, and an all-hex name or password enclosed in double quotes so readers take it as literal text rather than hex-encoded bytes. WPA2 and WPA3 both map to the standard WPA token, because a nonstandard token breaks parsers.
• Contact cards are vCard 3.0 (RFC 2426), chosen over MECARD for broader field support and better scanner coverage, with CRLF line endings and the backslash, semicolon, comma and newline escaped in text values. The card on this page is 8 lines and 159 characters, which is why contact codes are the densest symbols in the table above.
• Phone, SMS, email and locations use the standard URI schemes. tel: (RFC 3966) carries the number normalized to E.164 — a plus sign, the country code and the national number, with spaces, dots, dashes and parentheses removed, and a number without a country code refused rather than guessed. sms: (RFC 5724) takes an optional ?body=, and mailto: (RFC 6068) takes a subject and body as percent-encoded parameters; geo: (RFC 5870) carries a latitude and longitude. The engine carries a note the SMS generator shows next to its result, and it is the only claim this site makes about whether a pre-filled SMS body will appear: "Pre-filled message support varies by platform: some phones open the composer with the text, others ignore it. The number always works."
• WhatsApp codes are https://wa.me/ links built to WhatsApp's click-to-chat rule — "Omit any zeroes, brackets, or dashes when adding the phone number in international format" — with the plus sign dropped as well, and an optional pre-filled message as ?text=, URL-encoded.
• Calendar events are a VEVENT wrapped in VCALENDAR (RFC 5545), with the start and end in UTC and CRLF line endings. The engine attaches a caveat the event generator shows verbatim: "Calendar QR codes are less reliable than other types: native camera app support is inconsistent, and some phones show the raw text instead of an add-to-calendar prompt. Test on the devices your audience uses."
• Plain text passes through unchanged; the QR byte segment carries UTF-8, so the text is encoded as typed.

The conventions are explained builder by builder in The WiFi QR payload format, vCard contact QR codes and URI schemes: mailto, tel, sms and WhatsApp.

Every code this site produces is a static QR code: the data is encoded directly into the image itself. There is no redirect through our servers, which means there is nothing we could switch off, paywall, or let expire — the code keeps working even if this site disappears. Services that offer "dynamic" codes route every scan through their own domain, which is precisely what lets them disable your code when a trial ends. Read the full comparison on the about page.

The optional free account changes none of this. Saving a code just stores a copy so you can re-download it later — the printed code itself never depends on us.

The trade-off is stated plainly rather than sold around: a static code cannot be edited after printing, and scans cannot be counted. A changed password or a moved page means a new code, and the old printouts keep carrying the old content for as long as they circulate. The guide Static versus dynamic QR codes sets out both sides.

The engine validates format, not truth. It can confirm that a URL has a protocol, that a phone number has a country code and a plausible number of digits, that an email address has the shape of one, that a WPA passphrase has an acceptable length and that every delimiter in a WIFI: string is escaped. It cannot know whether the password is correct, whether the number is reachable, whether the mailbox exists or whether the URL is safe. A wrong password encodes exactly as well as the right one — the symbol facts are identical — and a code that scans cleanly is not evidence that its contents are right. Check each field against its source before printing, because the only way to find such a mistake afterwards is to scan the print and read what the phone shows.

Two more things the symbol facts do not settle. The print-size readout is arithmetic and the contrast check is a formula; neither is a scan. And the delivery row's "Share to WhatsApp" sends text, not images: for the link in the worked example the engine's share plan is the link itself, which is equivalent to scanning the code, while for the WiFi payload the plan is a note rather than a broken share — both checked when this page was built. The note reads: "WhatsApp sharing sends text, not images — and this code’s content is not a link, so pasting it into a chat would be meaningless. Download the PNG and attach it in WhatsApp instead."

• Cropping the quiet zone. The 4-module white border is part of the symbol as the standard defines it. The renderer always draws it and offers no way to disable it; trimming it away in a layout program, or printing the code flush against artwork, is the most common self-inflicted scan failure.
• Inverting the colours. The style panel warns below 4.5:1 and warns separately for light-on-dark codes, which many scanners reject — the inverted pair above assesses at 17.40:1 and is still warned about.
• Expecting a wrong password to fail. The code encodes whatever was typed. Format is checked; truth is not. A scan that shows a join prompt and then fails to join is, as far as the engine can tell, indistinguishable from one that works.
• Treating the logo as content. The optional logo in the style panel is drawn over the symbol, not written into the payload. Adding one forces error correction H and is capped at 16% of the symbol area.
• Expecting a larger PNG to be a different code. It is the same symbol at a larger module pitch; the version and the module count are fixed by the payload, as the tables above show.
• Expecting the content type to set the size. The encoder sees text, not types. A short payload of any kind is a small symbol and a long payload of any kind is a dense one — the phone call and the contact card in the table differ by 7 versions because their payloads differ by 142 characters.

There are 8 guides behind the generator pages. Each is written against the methodology, and every payload, version, module count, ratio and print size in them is computed at build time by the same engine that powers the generator above, on fictional inputs, so the explanations cannot drift from the tool:

• How a QR code encodes data — the two layers, with version and module counts computed on several payloads.
• Error correction and logos — why a logo forces level H, the decode-tested cap, and the geometry on fixed sizes.
• The quiet zone and print size — the border that cannot be disabled and the readout for every PNG preset.
• Contrast and inverted codes — the relative-luminance formula on several colour pairs, and the two warnings.
• The WiFi QR payload format — the WIFI: convention field by field, escaping, hex quoting and security types.
• vCard contact QR codes — vCard 3.0 over MECARD, CRLF line endings and escaping on fictional contacts.
• URI schemes: mailto, tel, sms and WhatsApp — the schemes, E.164 numbers, percent-encoding and the wa.me rule.
• Static versus dynamic QR codes — where the content lives in each kind of code and the trade-offs stated plainly.

All of them are listed on the guides index. If you only read one, read the first: the two-layer model is the one idea that makes the rest of the site predictable.

Test before you print: a QR code cannot verify that a password is correct or a link is safe — always scan a new code with a real device before printing or distributing it. How each generator is built, tested, and verified is documented on the methodology page.