Initializing, please wait a moment

QR Code Content Types: URL vs vCard vs Wi-Fi vs Text - Which to Pick

Last reviewed 2026-05-06. Targeted at the moment you sit down to make your first QR code and the generator asks "what kind of payload?". Routes the actual generation to QR Code Generator (in-browser, no upload).

30-second answer. Four content types cover almost every real-world QR code: URL (a web link - by far the most common), vCard (a contact card that prompts the scanner to save a contact), Wi-Fi (a network credential that prompts the scanner to join), and plain text (a short note shown as text). The scanner app on each phone reads a special prefix at the start of the payload (https://, BEGIN:VCARD, WIFI:) and switches behaviour accordingly. Pick by what you want the scanner to do: open a page (URL), save a contact (vCard), join a network (Wi-Fi), or just display some text.

What is actually inside a QR code?

A QR code is, mechanically, a square of black and white modules that encode a string of bytes. The QR specification (ISO/IEC 18004) does not define what string to put in - it just defines how to encode any string into the visual pattern. The "content type" of a QR code is purely a convention agreed between QR generators and scanner apps about what prefix the string starts with. When a scanner reads https://example.com, it sees the https:// prefix and treats the payload as a URL; when it reads BEGIN:VCARD, it treats the payload as a contact card. The QR code itself does not "know" the type; the prefix tells the scanner.

Three places define the prefix conventions in practice. First, RFC-registered URI schemes (http, https, mailto, tel, geo, sms) are the formal Internet standards that scanners trust without question. Second, RFC 6350 vCard 4.0 (and the older RFC 2426 vCard 3.0) defines the contact-card text format - if a QR payload starts with BEGIN:VCARD, it follows that format. Third, the ZXing project wiki - the canonical open-source QR decoder used in many scanner apps - documents a small set of de-facto prefixes that have no formal IETF spec but are universally implemented; the most important is the WIFI: URI scheme that iOS Camera, Android Camera, and Google Lens all interpret as a network-join request. Understanding which of the three sources backs your chosen content type tells you how reliably it will scan across phones from different manufacturers.

Type 1: URL - the most common type

A URL QR code is the simplest payload: the literal characters of the URL, including the https:// prefix. For example, https://freetoolonline.com/qr-code-generator.html encoded directly. Every scanner app on every modern phone recognises this and offers to open the URL in the default browser; many also auto-open it when the camera is pointed at the code from a "viewfinder" prompt without the user explicitly tapping.

The https:// prefix matters: a payload of just freetoolonline.com without the scheme is technically a plain-text payload, and most scanners display it as text rather than offering to open it. Always include the scheme. For shorter codes, https:// is also slightly longer than http:// at the byte level, but the difference is one byte and modern scanners require https:// for security warnings to behave correctly - never drop the s to save a byte.

When to pick URL. Conference table tent that opens an event landing page; restaurant menu that opens an online menu; product packaging that opens a how-to video; flyer that opens a registration form; email signature that opens your portfolio. Any scenario where the desired action is "open this web page in a phone browser" is a URL QR code.

Type 2: vCard - for contact cards

A vCard QR code encodes a contact card in the RFC 6350 vCard 4.0 format (or the older RFC 2426 vCard 3.0; both are still in active use). The payload starts with BEGIN:VCARD and ends with END:VCARD, with name, phone, email, organisation, and URL fields between. A minimal vCard 3.0 looks like:

BEGIN:VCARD
VERSION:3.0
N:Smith;Jane
FN:Jane Smith
ORG:Example Corp
TEL:+1-555-0100
EMAIL:jane@example.com
URL:https://example.com/jane
END:VCARD

When a scanner reads this, it offers to save the contact - typically by opening the phone's contacts app pre-filled with the fields, ready to confirm. iOS Camera, Android Camera, Google Lens, and most third-party QR scanner apps all support vCard payloads.

The trade-off is payload length: a complete vCard with name, phone, email, organisation, address, and URL is often 200-350 bytes, which produces a dense QR code that is harder to scan at small print sizes. Two practical mitigations: (a) keep the vCard minimal (name, single phone, single email - skip address and organisation if they are not essential), and (b) print the QR code at least 3 cm x 3 cm so the dense pattern stays legible from typical scan distances. The companion guide on payload size at QR Code Error Correction and Scan Failures covers the size-vs-payload trade-off in detail.

MECARD: a smaller vCard alternative. An older format called MECARD (originated by NTT DoCoMo for Japanese feature phones) uses the prefix MECARD: and a more compact field syntax: MECARD:N:Smith,Jane;TEL:5550100;EMAIL:jane@example.com;;. MECARD payloads are typically 30-40% shorter than the equivalent vCard, which produces a sparser, easier-to-scan code. Most modern scanners (iOS Camera, Android Camera, Google Lens, ZXing-based apps) recognise MECARD; older scanners may not. If your audience is global and mostly on current-stable phones, MECARD is a good choice when print size is constrained; otherwise vCard 3.0 is the safer default.

When to pick vCard or MECARD. Business card with a "scan to save my contact" QR; lanyard at a conference; event-staff badge that lets attendees grab the organiser's contact; printed real-estate flyer with the agent's contact pre-filled. Any scenario where the desired action is "save this person's contact details to the phone" is a vCard or MECARD QR code.

Type 3: Wi-Fi - for joining a network

A Wi-Fi QR code encodes a network credential that prompts the scanner to join the network. The format is documented in the ZXing project wiki and is implemented natively by iOS Camera (since iOS 11), Android Camera (since Android 10 on Pixel; varies on other vendors), and Google Lens. The payload syntax is:

WIFI:S:<ssid>;T:<auth_type>;P:<password>;H:<hidden>;;

Where S: is the network name (SSID), T: is the authentication type (WPA for WPA / WPA2 / WPA3, WEP for legacy WEP, nopass for open networks), P: is the password (omit for open networks), and H:true marks the network as hidden (most networks omit this field). A typical café-Wi-Fi code looks like: WIFI:S:CafeGuest;T:WPA;P:welcome2026;;. Note the trailing double semicolon - it terminates the payload.

The Wi-Fi format has no formal IETF RFC; it is a de-facto standard documented in the ZXing wiki and implemented by the major camera apps. This means that on a current-stable iPhone or Pixel the code "just works", but on older phones (pre-iOS 11; pre-Android 10 on most non-Pixel vendors) the payload may display as raw text rather than triggering a network-join prompt. For mixed audiences, print the SSID and password as plain text underneath the QR code so users with older phones can still join manually.

Special characters in passwords. If the SSID or password contains a literal ;, :, ,, ", or \, those characters must be backslash-escaped in the payload (\\;, \\:, etc.). Most QR generators handle this automatically, but if you are hand-editing a payload it is the most-common source of "the code generated but my phone refuses to join" reports.

When to pick Wi-Fi. Café guest-network on a table card; coworking-space welcome packet; conference green-room handout; Airbnb listing that pre-shares the code in the welcome message. Any scenario where the desired action is "let the visitor join my Wi-Fi without typing a password" is a Wi-Fi QR code.

Type 4: Plain text - for short notes

A plain-text QR code is the literal characters of the text, with no special prefix. When a scanner reads it, the text is displayed in a "scanned content" panel and the user can copy it to the clipboard. There is no auto-open, no auto-save, no auto-join - just text on screen.

Plain text is the right choice when none of the other types fits: a Wi-Fi password where you do not want auto-join (you want the user to copy and paste it themselves), a short serial number on a piece of equipment, an event-day code, a Bitcoin address, a discount coupon code. The trade-off is that on most scanners plain text gets the lowest-friction UI - the user has to read the text and decide what to do with it - which is exactly right for some payloads (a coupon code) and exactly wrong for others (a 150-character URL that would have been better as a URL QR code).

When to pick plain text. Coupon code on a printed flyer; serial number on equipment; conference Wi-Fi password where the SSID is announced aloud and the QR holds only the password; cryptocurrency address; short note ("ask front desk for parking validation"). Any scenario where the desired action is "the user reads the text and types it manually somewhere else" is a plain-text QR code.

Decision: which type for which scenario

If you know what you want the scanner to do, the type is usually obvious. The mapping:

Open a web page in the browser → URL.
Save a contact to the phone → vCard (or MECARD if print size is small).
Join a Wi-Fi network → Wi-Fi. Print SSID and password as plain text alongside for older phones.
Display a code or note for the user to copy → plain text.
Compose an email → mailto:. Pre-fill subject and body for clarity.
Place a phone call → tel:. Always include the international country code.
Send a pre-filled SMS → smsto:.
Open a map at a location → geo:.
Add a calendar event → VEVENT (test scanner support first).

When in doubt between two options, pick the one with the shorter payload - shorter payloads produce sparser, more reliable codes. A short URL that redirects to a long URL is almost always more reliable than encoding the long URL directly; the redirect carries the tracking parameters server-side.

Payload size, error correction, and the scan-reliability trade-off

QR codes have a fixed maximum payload at each size; the longer the payload, the denser the pattern, and the larger the print size you need to keep it scannable. As a rough guide: a 25-character URL produces a sparse code that scans from a metre away on a phone camera; a 200-character vCard produces a dense code that needs to be at least 3 cm x 3 cm and scanned from no more than 30 cm. The dedicated guide at QR Code Error Correction and Scan Failures covers the four error-correction levels (L / M / Q / H) and the size-vs-payload trade-off, with concrete print-size recommendations per scenario.

Two practical defaults that work for almost every print scenario: error-correction level M (~15% damage tolerance) for indoor use and level Q (~25%) for outdoor or worn surfaces; a minimum size of 2 cm x 2 cm for short payloads (URL under 50 chars), 3 cm x 3 cm for medium payloads (vCard, Wi-Fi), and 4 cm x 4 cm for long URLs over 100 characters. Anything smaller and a meaningful share of phones will fail to scan.

Privacy: what a QR code does and does not encode

A QR code encodes only the literal payload string. There is no IP address, no device ID, no timestamp, no location, no analytics data hidden in the pattern - the code is exactly what you put into it, nothing more. Generating a QR code locally in the browser (which is what QR Code Generator on this site does) keeps the payload entirely on your device; nothing about your QR codes is sent to any server during generation.

If you encode a URL that points to a server-side analytics tracker or a URL with UTM parameters, the analytics happen on the receiving end when the scanner opens the URL - the QR code itself is just static bytes. Wi-Fi codes carry the literal password; treat printed Wi-Fi codes the same way you would treat the plain-text password (do not leave them in publicly photographable spots if the network is sensitive).