QR Code Examples: 9 Real Codes and What Each One Encodes

Each row is a real, valid payload in the format phones expect. The module count is the width of the resulting grid in small squares, measured with the same encoder this site generates with, at error correction M. The last column is the smallest width the code can be printed at and still meet the GS1 minimum module size of 0.396 mm, including the four-module quiet zone the specification requires.

Raising error correction, or adding a logo, increases the module count — the sizing section below covers that.

The vCard row above is the only one too long for a table cell, and it is also the one people most often get wrong, so here it is in full. Line breaks are part of the format:

BEGIN:VCARD
VERSION:3.0
N:Okafor;Ada
FN:Ada Okafor
ORG:Northwind Studio
TITLE:Creative Director
TEL:+441632960123
EMAIL:[email protected]
URL:https://northwind.example
END:VCARD

Two details matter. N: takes the surname first, separated by a semicolon, while FN: is the display name in normal order — both are required, and phones use them differently. And every field you add makes the code physically bigger: the nine lines above produce 53 modules, against 21 for a bare phone number. A contact card QR on a business card is the single most common case where a code is printed too small to scan.

Most broken QR codes are broken in the text, not the pattern. Four failures account for nearly all of them, and each one produces a code that scans perfectly and does the wrong thing — which is worse than one that does not scan at all, because it passes a visual check.

A link with no scheme. example.com/menu is not a URL as far as the format is concerned, it is plain text. The code scans, the phone shows the characters, and nothing opens. The fix is always to encode https://example.com/menu in full. This is the single most common broken URL code.

A Wi-Fi password containing a reserved character. The Wi-Fi format uses ; and : as its own separators, so a password like flat;white splits the string and the network entry is mangled. The reserved set is backslash, semicolon, comma, colon and double quote, and each has to be escaped with a backslash — WIFI:S:Cafe\; Bar;T:WPA;P:flatwhite2026;;. A Wi-Fi QR code generator should do this for you; if you are hand-writing the string, it is the thing to check first.

A contact card with a comma in a field. vCard uses ; and , structurally, so a company written as Northwind, Studio breaks the field it sits in. Those characters need escaping too, and a literal line break inside a value has to become \n rather than an actual newline.

A phone number with formatting in it. Spaces, brackets and dashes are fine for humans and unreliable in a tel: or WhatsApp payload — WhatsApp links in particular want digits only, with the country code and no plus sign. Write +441632960123, not +44 (0) 1632 960 123.

The common thread is that none of these produce a visibly different square. You cannot proofread a QR code by looking at it, which is why scanning the printed proof is not optional.

The useful question is usually not which type exists but which one suits the surface. These are the pairings that come up most, with the minimum width from the table above.

A restaurant table tent wants a URL code pointing at a hosted menu, not a PDF attachment. 13.1 mm is the floor, and in practice 25–30 mm is right for the distance people read a tent from. The restaurant guide covers the placement details.

A business card is the hardest surface here, because the contact card payload is the biggest in the table. At 53 modules it needs 24.2 mm to be legal at minimum module size, which is a large square on a card. Dropping the job title and website is often what makes it fit.

A café Wi-Fi card is the one case where the code genuinely replaces typing, and at 29 modules it stays small. Laminate it: this one gets handled.

A parking sign or a meter should be a code people can verify before trusting, because stickers placed over legitimate codes are a known problem in exactly this setting. Short, readable destinations help — a long obfuscated URL is indistinguishable from a malicious one in a camera preview.

Product packaging usually wants a code that can be repointed after the print run, which means a dynamic QR rather than any of the static payloads above. The printed square stays the same size regardless of where it eventually points.

A conference badge often carries a contact card so attendees can save each other without typing. Size it from the table, not from the space left in the layout.

Allergen or safety information is the case for a plain text code with no prefix at all. There is no page to host and no link to break, and it works with no signal.

Every example above is the same kind of black-and-white square, and they are not interchangeable in size. The grid grows with the amount of text, and the smallest printable width grows with it.

The practical consequence: you cannot design a layout with a fixed QR slot and then decide later what goes in it. A tel: code fits in 11.5 mm. Swap it for a contact card and the same slot needs 24.2 mm, more than double, or the code fails at the distance people actually hold a card.

Two ways to keep a code small when the content is long:

• Shorten what you encode. A dynamic QR encodes a short redirect rather than the destination, so the pattern stays the same size no matter how long the real URL is.
• Print it bigger. The QR code size guide has the per-surface measurements, and the rule of thumb is that code width should be roughly a tenth of the distance people scan from.

A common assumption is that any QR code can be edited after printing. It cannot, and which of the examples above can be is decided by what they encode.

A dynamic code works by encoding a short redirect — a URL on the generator's domain — instead of the real destination. Scanning it hits that redirect, which looks up where you have pointed it and forwards the phone. The printed pattern never changes; the lookup does.

That mechanism only exists for things a browser can follow. Of the ten examples above, the web link, the WhatsApp chat and anything else that is fundamentally a URL can be dynamic. The Wi-Fi login, the tel: number, the smsto: message, the geo: point, the plain text and the contact card cannot, because there is no web request in the middle to intercept. A phone handed WIFI:S:CafeGuest;... acts on that string locally and never contacts a server at all.

This has a practical consequence worth planning around. If the Wi-Fi password changes, every printed Wi-Fi code is dead and has to be reprinted — there is no dashboard that fixes it. If a menu URL changes and the code was dynamic, nothing printed needs to change. When a payload is going on something expensive and long-lived, that difference is usually the deciding factor, and it is covered in full in the static versus dynamic guide.

The workaround, where it matters, is to encode a URL even when the content is not naturally one — a short page that displays the Wi-Fi details, rather than a WIFI: payload. You trade the one-tap join for the ability to change the password without a reprint.

Lay the ten codes side by side and they are plainly the same kind of object, which is the thing that makes QR codes hard to reason about. The resemblance is structural, and the fixed parts are worth being able to name.

The three large squares in the corners are finder patterns. They tell a camera it is looking at a QR code at all, and from their relative positions it works out the orientation — which is why a code scans upside down or at an angle. Every example has exactly three, and nothing may overlap them.

The smaller square near the fourth corner, present on all but the very smallest codes, is an alignment pattern. It lets the scanner correct for the curve when a code is printed on a bottle, a cup or anything else that is not flat.

The dotted lines running between the finder patterns are the timing pattern, a fixed alternation that tells the scanner how wide one module is.

The blank margin around everything is the quiet zone, and it is part of the specification rather than a design preference. Four modules on every side, and the most common cause of a code that fails on press is a designer tightening that margin to fit a layout.

Everything else — the apparently random speckle in the middle — is the data, plus the error-correction copies of it. That is the only part that differs between a Wi-Fi code and a contact card, and it is why a logo QR code works at all: the redundancy means a scanner can rebuild the modules a logo covers, as long as it stays off the three corners.

A good share of people searching for QR code examples are not trying to encode anything. They want a code image to drop into a mockup, a slide or a packaging comp.

If that is you, generate a real one with the image QR generator rather than copying a sample from a search result. It is free and takes seconds, and it avoids the failure mode that matters: a placeholder code looks identical to a real one, so nobody reviewing the layout can tell by eye whether it points at your campaign or at whatever the original sample encoded. Printed material does ship with sample codes still in it, and it is invisible until a customer scans it.

Generate the placeholder against your own domain, export SVG so it scales without softening, and scan the final printed proof with a phone that has never seen the code. The image and photo QR guide covers that case in more detail.

Because the text inside a code is just text, you can check it. On most modern phones the camera shows the destination as a preview before opening anything, and that preview is the string itself for tel:, smsto: and plain-text codes.

This is worth doing with any code in a public place. A sticker placed over a legitimate code on a parking meter or a menu is indistinguishable from the original by eye, and the only difference is the text underneath. A QR scanner that shows the raw string before opening it removes the guesswork, and how to scan QR codes covers doing it from a screenshot or a saved photo.