QR Codes · 8 min read · Updated September 15, 2026

QR Codes That Are Not Links: WiFi, Email, SMS, Events and Maps

Almost every QR code you meet contains a URL, so it is easy to assume that is all they can hold. It is not. The same square can hand someone your WiFi password, open a half-written text message, drop a pin on a map, or put an event straight into a calendar, with no app and no typing.

What makes that work is a set of small text conventions that phone cameras recognise. This guide covers the formats worth knowing, what each one actually does when scanned, and the significant catch that applies to every one of them.

A QR code is just a container for text

A QR code encodes a string of characters, nothing more. When a URL is in there, your camera recognises the shape of a web address and offers to open it. The same recognition happens for several other patterns: a string beginning WIFI: is treated as network credentials, one beginning geo: as a coordinate, one beginning SMSTO: as a text message.

None of this is part of the QR standard itself, which is only concerned with turning characters into a printable grid. It is a layer of conventions that camera apps and operating systems agreed on over time, which is why support is good but not universal, and why testing matters more here than it does for a plain link. For how the grid itself works, see how QR codes work.

The formats worth knowing

WiFi: the one people actually use

This is the format worth learning first, because guests asking for the WiFi password is a universal small annoyance and a printed code solves it completely. The payload is a short list of fields separated by semicolons.

WIFI:T:WPA;S:Cafe Guest;P:flat white 47;;

• T is the encryption type: WPA covers WPA, WPA2 and WPA3, WEP for older networks, and nopass for an open network, where you then omit the password field entirely.
• S is the network name, exactly as it is broadcast, including capitals and spaces.
• P is the password.
• H is optional and set to true only for a hidden network that does not broadcast its name.

Two details cause most failures. The field order matters, so T comes before S before P. And the payload ends with two semicolons, not one, which is a genuine part of the format rather than a typo. If your network name or password contains a backslash, semicolon, comma or colon, each one has to be escaped with a preceding backslash, or the parser will read it as a field separator and silently produce the wrong credentials.

Build one with the WiFi QR code generator, which handles the escaping and the terminator for you. Worth remembering before you print it at poster size: anyone who can see the code can read the password off it, so it belongs on a guest network rather than the one your point-of-sale terminal sits on.

Email, text messages and phone numbers

These three are the simplest formats and they share a shape: a scheme, a destination, and optional content to prefill. A mailto: payload accepts the same query parameters a mailto: link accepts in a browser, so you can populate the subject and body as well as the recipient.

mailto:[email protected]?subject=Table%20booking&body=For%20four%2C%20Friday

SMSTO:+15551234567:Send me the menu

The SMSTO: form is the one with the broadest support, and its structure is the number, a colon, then the message. Because the colon separates those two parts, a colon inside the message itself has to be escaped, and the same applies to semicolons and backslashes. The email and SMS generators handle that.

A prefilled message is more useful than it first looks. A code on a table tent that opens a text reading "Send me the menu" turns a request into one tap, and because the message arrives from the customer, you now have a conversation rather than a scan you cannot reply to.

Calendar events

An event code carries a small iCalendar document, the same format .ics files use. It is more verbose than the others because it has to express dates unambiguously, but the result is a code that puts a workshop, a fixture or a deadline directly into somebody's calendar with the location and description attached.

BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:Product workshop
DTSTART:20261014T090000Z
DTEND:20261014T103000Z
LOCATION:Studio 3, 14 Rope Street
END:VEVENT
END:VCALENDAR

The timestamps are the part to get right. A Z suffix means the time is in UTC, which is the safest choice for an audience in more than one timezone, since every calendar app converts it correctly on arrival. Drop the Z and the time is interpreted as local to whoever scans it, which is what you want for something like a shop opening and wrong for almost everything else. The event QR generator builds the whole document from a form.

Map locations

A geo: payload is a latitude and longitude separated by a comma, and it is the shortest format here. Scanned on Android it opens the default maps application at that point. On iOS, handling is inconsistent: some apps take it, and the Camera app has historically been unreliable with it.

geo:51.5033,-0.1196

Because of that inconsistency, a geo: code is a reasonable choice for a venue with a predominantly Android audience or an internal use where you control the devices. For a public-facing sign, a plain URL to a map listing is more dependable, works everywhere, and has the significant advantage covered in the next section. The geo QR generator produces the coordinate form when you want it.

The catch: none of these can be tracked or changed

This is the tradeoff that decides which format you should actually use, and it follows from how these codes work. A WiFi, SMS, event or geo code contains the whole payload inside the printed square. Nothing is fetched. No server is contacted. The phone reads the grid and acts on what it finds.

Two consequences, and both are permanent once the code is printed. You cannot count scans, because there is no request anywhere to count. And you cannot change what it does, because changing it means printing a different code and replacing every copy already in the world. Move the event, and every poster now adds the wrong time to people's calendars.

So the rule is simple. Use a non-URL format when the payload genuinely is the content and will never change: a WiFi password on a guest network, a phone number on a van. Use a URL pointing at a short link whenever you want to know whether the code worked, or might need to change where it goes. For an event, a code pointing at a page that holds the details beats one holding the details directly, precisely because the page can be corrected and the poster cannot. Tracking QR code scans covers that setup.

Test before you print

Support for these formats varies by operating system, by camera app and by which mail or calendar application somebody has set as their default. That variability is manageable, but only if you find it before a print run rather than after.

1. Scan it with an iPhone and an Android phone, using the built-in camera rather than a scanner app, because that is what people will actually use.
2. Confirm the prompt says what you expect. A WiFi code should name the right network; an event should show the right date in the local timezone.
3. Decode the raw payload with a QR code reader to check the escaping, which is where a stray semicolon shows up as a truncated password.
4. Print one at the real size on the real material and scan it from the distance people will stand at, since contrast and paper finish matter more than screen tests suggest.