vCard QR Codes: RFC 6350 Field Reference Guide 2026
A vCard QR code lets someone scan your phone and save your contact in one tap. The catch: vCard is an actual 40-plus-field standard, and most QR generators implement a tiny subset incorrectly. If you have ever scanned a vCard and gotten a contact with the phone number in the notes field or the photo silently dropped, you have hit one of the field-support bugs this guide explains. We cover every RFC 6350 field that matters, show a working vCard 4.0 payload with an inline photo, and list the parsing quirks for iOS, Samsung, and Pixel as of April 2026.
Quick answer
A vCard QR code embeds a full text vCard payload (RFC 6350 for version 4.0 or RFC 2426 for version 3.0) into a QR code. Most smartphones recognize the BEGIN:VCARD opener and offer to save the contact on scan. Use vCard 3.0 for maximum compatibility with older Android phones. Use vCard 4.0 if you need UTF-8 names, timestamped fields, or the KIND:org record type. For most business cards, MECARD is a simpler alternative that avoids several vCard parser bugs on older phones.
Table of contents
- vCard 3.0 vs 4.0 differences
- BEGIN and END structure
- Every field that matters
- A working vCard 4.0 with inline photo
- MECARD: the simpler alternative
- Why LinkedIn uses URLs not vCards
- Phone importing quirks (Samsung, iOS, Pixel)
- Payload size and QR version math
- FAQ
vCard 3.0 vs 4.0 differences
vCard 3.0 was defined in RFC 2426 back in 1998 and remains the most widely supported version. Almost every phone ever made reads vCard 3.0 correctly. Its main limits are ASCII-biased text handling and a flat structure that cannot express richer relationships.
vCard 4.0 was defined in RFC 6350 in 2011. It introduces UTF-8 native support, a more consistent structured name field, the KIND property for distinguishing individual contacts from organizations, and support for RFC 5545 iCalendar-style date-time stamps. The trade-off is inconsistent parser support. iOS 17 and newer handle 4.0 cleanly. Android 14 handles it cleanly on Pixel but partially on Samsung devices.
For a business card QR that needs to work on every phone, use vCard 3.0. For developer tools and enterprise contact distribution, use 4.0.
BEGIN and END structure
Every vCard starts and ends with the same two lines:
BEGIN:VCARD
VERSION:4.0
...fields...
END:VCARD
Any content before BEGIN:VCARD or after END:VCARD must be ignored by parsers. In practice, some Android parsers silently accept garbage before the begin line, and some reject it. To stay safe, start your payload with BEGIN:VCARD as the first character of the QR text.
Line endings are CRLF (\r\n) per the RFC. In practice, lone LF is accepted by every major parser. Mixed line endings inside a single payload cause some Windows-based scanners to reject the card, so pick one style and stick with it.
Every field that matters
Here is a reference table of the fields you actually need for a contact card. Full RFC 6350 defines over 40 properties, but the ones below cover roughly 98 percent of real-world vCard QR use.
| Field | Purpose | Example |
| FN | Formatted name (display) | FN:Ayush Nigam |
| N | Structured name (family, given, middle, prefix, suffix) | N:Nigam;Ayush;;; |
| ORG | Organization | ORG:QRCrack |
| TITLE | Job title | TITLE:Founder |
| TEL | Phone with type | TEL;TYPE=CELL,VOICE:+15551234567 |
| Email with type | EMAIL;TYPE=WORK:alice@example.com | |
| URL | Website | URL:https://qrcrack.com |
| ADR | Structured address (pobox, ext, street, city, region, code, country) | ADR;TYPE=WORK:;;123 Main St;Austin;TX;78701;USA |
| NOTE | Free-form note | NOTE:Founding team, also QR enthusiast |
| PHOTO | Inline or URL photo | see below |
| BDAY | Birthday | BDAY:19941215 |
| REV | Revision timestamp | REV:20260415T120000Z |
FN is required, N is recommended
In vCard 4.0, only FN (formatted name) is required. In vCard 3.0, both FN and N are required. If you omit N, iOS saves the contact but populates only the first name. Samsung phones from One UI 5.0 and newer mark the contact as "incomplete" and prompt for a family name on first open.
TEL type matters
The TYPE parameter on TEL determines how the phone files the number. CELL goes to the mobile slot, WORK to the work slot, HOME to the home slot, and unknown types fall into "other". iOS recognizes iPhone as a synonym for CELL. Android does not.
A working vCard 4.0 with inline photo
Here is a complete vCard 4.0 with an inline PNG photo encoded in base64:
BEGIN:VCARD
VERSION:4.0
FN:Ayush Nigam
N:Nigam;Ayush;;;
ORG:QRCrack
TITLE:Founder
TEL;TYPE=cell:+15551234567
EMAIL;TYPE=work:ayush@qrcrack.com
URL:https://qrcrack.com
ADR;TYPE=work:;;100 Congress Ave;Austin;TX;78701;USA
PHOTO:data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAZdEVYdFNvZnR3YXJlAFBhaW50Lk5FVCB2My41LjExR/NCNwAAAAtJREFUOE9jGAWjAAAAggABJUHfjwAAAABJRU5ErkJggg==
REV:20260415T000000Z
END:VCARD
The PHOTO base64 payload inflates the total size quickly. A 100 by 100 pixel PNG is roughly 2 KB after base64 encoding. Adding it pushes the QR code to version 18 or higher (roughly 89 by 89 modules), which is hard to print below 5 cm square. For business cards, prefer a PHOTO URL field pointing to a hosted image.
MECARD: the simpler alternative
MECARD is a compact contact format designed purpose-built for QR codes. It was created by NTT DoCoMo for Japanese feature phones and later popularized by Android. The syntax looks like this:
MECARD:N:Nigam,Ayush;TEL:+15551234567;EMAIL:ayush@qrcrack.com;URL:https://qrcrack.com;;
MECARD is not a standard in any formal sense, but every major Android phone recognizes it. iOS support is partial: iOS 18 reads MECARD but stores fewer fields than it would from a vCard. For Android-first audiences, MECARD shrinks the QR payload by 40 to 60 percent compared to an equivalent vCard, which means a smaller code at the same ECC level.
Why LinkedIn uses URLs not vCards
LinkedIn's "Share profile" QR code is a plain URL pointing to your LinkedIn profile page, not a vCard payload. Three reasons:
- Centralized updates: Scanning a URL always gets the current profile. A vCard captures a snapshot that goes stale as job titles and roles change.
- Payload size: A LinkedIn URL fits in 50 ASCII bytes. A full vCard for a mid-career profile runs 300 to 800 bytes.
- Tracking: LinkedIn wants the scan event logged server-side. A raw vCard scan happens entirely on the scanner's device, invisible to LinkedIn.
Business card QR codes face a similar trade-off. Use a vCard when you want the contact saved without internet access. Use a URL (typically pointing to a digital business card page) when you want analytics and updatability.
Phone importing quirks
iOS 18
iOS recognizes both vCard 3.0 and 4.0 from QR codes starting with BEGIN:VCARD. The camera app shows a prompt reading "Add to Contacts" on scan. Behavior quirks:
- The NOTE field is truncated at 999 characters. Longer notes are silently cut.
- The PHOTO field is applied only if base64-encoded and smaller than 10 KB. Larger payloads decode but iOS skips the photo.
- Multiple TEL fields are accepted and filed by type.
- UTF-8 names work. Emoji in FN is accepted but sometimes renders as a box on older Apple Watch models.
Samsung One UI 6.1 (Android 14)
Samsung's contact app imports vCards through the Bixby Vision scanner or the built-in QR reader. Quirks:
- The PHOTO field is ignored for vCard 4.0 inline photos. URL-referenced photos work.
- TYPE parameters are case-sensitive on some One UI 6.1 builds, which violates the RFC. Use lowercase
cell,work,homefor maximum compatibility. - ADR fields with empty leading semicolons (as the RFC mandates for missing PO Box) sometimes get parsed with the fields shifted.
Pixel (Android 14 and 15)
Pixel uses Google Contacts for import. Quirks:
- Most consistent parser of the three.
- Accepts both 3.0 and 4.0 cleanly.
- Large PHOTO fields (up to 100 KB) are accepted.
- REV timestamps are ignored (stored but not surfaced in the UI).
Payload size and QR version math
A typical minimal vCard (name, phone, email, URL) is about 120 to 180 bytes. At ECC level M, this fits in a version 8 QR code (49 by 49 modules). Add a 500-byte photo URL and you push to version 10. Add an inline base64 PNG and you jump to version 18 or higher.
Recommendation: keep the payload below 300 bytes for QR codes printed below 3 cm square. Above that, the modules become too small for older phone cameras to resolve at normal scanning distance (25 cm).
FAQ
Which vCard version should I use for QR codes?
vCard 3.0 if compatibility with older phones matters. vCard 4.0 if you need UTF-8 or timestamp support. MECARD for Android-heavy audiences where payload size matters.
Can I include social media profiles?
RFC 6350 defines the X-SOCIALPROFILE extended property, but parser support is weak. Stick to URL fields with descriptive labels, like URL;TYPE=x:https://x.com/handle.
Why does my photo not show up on Samsung?
Samsung phones running One UI 6.x ignore inline PHOTO fields in vCard 4.0. Use a PHOTO URL pointing to a hosted image and the phone will fetch it on import.
Is there a maximum vCard size?
RFC 6350 sets no hard limit. In practice, keep the payload below 2 KB to stay within QR code printability. Above 2 KB, the code needs a physical size of 10 cm or more to scan reliably.
Can I encode multiple contacts in one QR?
Yes, concatenate multiple vCards (each with its own BEGIN and END) back to back. iOS prompts once and lets the user pick which contacts to save. Android behavior varies by manufacturer.
Sources
- RFC 6350 vCard Format Specification (vCard 4.0, 2011)
- RFC 2426 vCard MIME Directory Profile (vCard 3.0, 1998)
- Apple Developer Documentation on Contacts import (2025)
- Google ZXing source code at github.com/zxing/zxing
- QRCrack parser compatibility test suite, March 2026
Use QRCrack's vCard QR generator to build a vCard 3.0 or 4.0 payload with every field this guide covers, preview it on iOS and Android sizing, and export as PNG, SVG, or PDF. Fully client-side, no signup.
_By the QRCrack engineering team. Published April 15, 2026. Last verified 2026-04-15._