vCard QR Codes for Business Cards: What to Include, What to Skip

A QR code on a business card promises something simple. Someone points a phone at it, taps the prompt, and your name, number, and email land in their contacts without a single keystroke. The promise holds up, but only if you understand what the square actually contains. Most people treat the code as a bottomless container. It is not. Every field you add makes the pattern denser, and past a certain point a denser pattern scans worse and fails more often on a cheap camera in a crowded room.

The trick is knowing which fields earn their place and which ones belong somewhere else. This post covers the payload format behind a contact QR code, the fields phones read without complaint, how size trades off against reliability, the print details that decide whether a scan works, and the one case where a raw contact code is the wrong choice.

What a vCard QR code actually contains

A QR code does not store a "contact." It stores text. The magic is a convention: if the decoded text starts with a specific header, the phone's camera app recognizes it as a contact and offers to save it. There are two conventions in common use, and the difference matters.

The first is vCard, written as VCARD inside the code. It is the same format your phone exports when you share a contact as a .vcf file. A minimal vCard looks like this:

BEGIN:VCARD
VERSION:3.0
FN:Jordan Lee
TEL:+15551234567
EMAIL:jordan@example.com
END:VCARD

Each line is a field. FN is the formatted name, TEL is a phone number, EMAIL is an address, and the BEGIN and END lines mark the boundaries. The format supports dozens of fields, but the phone side decides which of them actually work.

The second convention is MECARD, an older and more compact format from the early mobile world. The same contact in MECARD reads MECARD:N:Lee,Jordan;TEL:15551234567;EMAIL:jordan@example.com;;. It is shorter, which produces a smaller code, but it supports fewer fields and gets read less consistently on modern phones. For a business card aimed at a general audience, vCard is the safer default. Both iOS and Android handle it natively, and it is the one this post assumes from here on.

Which fields phones reliably parse

The vCard spec is generous. Phones are not. A field in the standard is not the same as a field your recipient's phone will import cleanly, and that gap is where contact codes go wrong.

Five fields work everywhere. The formatted name (FN), the phone number (TEL), the email address (EMAIL), the organization (ORG), and the job title (TITLE) all import reliably on current iOS and Android. A website URL (URL) is a close sixth: it lands in the notes or website field on most phones and is worth including when your online presence is the point of the card.

Below that tier, results get uneven. Structured mailing addresses (ADR) parse inconsistently, and the multi-part syntax is easy to malform. Embedded photos (PHOTO) technically work but bloat the payload, which we will get to. Social handles, custom labels, and phonetic name fields are hit or miss, and often import as raw text the recipient has to clean up by hand.

The practical rule: put the fields that must reach the phone in the code, and nothing else. For most people that is name, one phone number, one email, the company, and the title. Everything beyond it is weight.

Why a bigger payload scans worse

A QR code is a fixed grid of black and white modules, and the amount of data it holds is set by its version, which ranges from version 1 (a 21 by 21 grid) up to version 40 (177 by 177). More data forces a higher version, which means more modules packed into the same printed square. Smaller modules are harder for a camera to resolve, especially at an angle, in poor light, or on a slightly smudged card.

A name, number, and email fit comfortably in a low version with large, forgiving modules. Add a full mailing address, two phone numbers, a website, and a social handle, and the version climbs. An embedded photo can push it to the point where the code will not scan from a printed card at business card size.

The lesson is to spend fields deliberately. Each one you cut lowers the version, enlarges the modules, and widens the range of conditions under which the scan succeeds. On a small printed card scanned in unpredictable light, that margin is the whole game.

Error correction and why it costs you data

QR codes carry redundancy so they still scan when part of the code is dirty, scratched, or obscured. This is called error correction, and it comes in four levels: L (low, about 7 percent recoverable), M (medium, about 15 percent), Q (quartile, about 25 percent), and H (high, about 30 percent). A code at level H can lose almost a third of its area and still decode, which is how a logo can sit in the center without breaking the scan.

The catch is that error correction is not free. The redundant data lives in the same grid as your contact details, so a higher level leaves less room for the payload and pushes the version up. Level H on a data-heavy vCard forces a noticeably denser code than the same vCard at level M.

For a business card, level M is the sensible middle. It survives the normal wear a card picks up in a wallet without inflating the code. Reach for Q or H only if you are placing a logo over the center or printing on a surface that scuffs easily, and keep the payload lean so the higher level does not push the density too far.

Print size and the quiet zone

A QR code that scans perfectly on screen can fail completely on paper, and the reason is usually size or margin.

Size first. A rough working minimum for a printed contact code is about 2 by 2 centimeters, a little under an inch square. Denser codes need to be larger, which is another reason to keep the payload small: a lean code stays scannable at business card scale, while a bloated one needs more room than the card can spare.

Then the quiet zone. Every QR code needs a margin of empty space around it, traditionally four modules wide, so the scanner can tell where the code ends and the rest of the card begins. Cropping the code tight against text or a border is the single most common cause of a card that will not scan. Leave the margin. It is not decorative padding, it is part of the code. For choosing the right file and resolution for print, our note on PNG, SVG, or PDF for a printed QR code covers the format tradeoffs.

The static tradeoff nobody mentions

Here is the honest limitation of a vCard QR code. The data is baked into the pattern. The code is a picture of your contact details, frozen at the moment you generated it. There is no server in the loop, no redirect, no way to change what the code says after it is printed.

That is a feature and a trap at once. The feature is that the code works forever, offline, with no dependency on any service staying online. The trap is that the day your phone number changes, every card you printed becomes a dead code. The person who scans it saves an old number and never reaches you. You cannot update a stack of printed cards, you reprint them.

For details that stay stable over the life of a print run, this is fine. Most people keep the same mobile number and email for years. If any field is likely to change, baking it into a static code is a decision to reprint later.

When a raw vCard is the wrong choice

The static nature draws a clean line between when a contact code fits and when it does not.

Use a raw vCard code when the details are stable and you want the scan to work without a network. A personal business card with your long-standing number and email is the ideal case, as is a card handed out where signal is unreliable, since a static code needs no connection to resolve.

Do not use a raw vCard when the information changes often, or when the card represents a role rather than a person. A card that says "Sales Team" and lists whoever currently holds the desk phone should not hardcode that number. A card for a job you might change should not freeze your current title. In all of these, encode a URL to a contact page instead. The code then holds a short link, the link stays fixed, and the page behind it can be edited any time. Your number changes, you update one web page, and every card already in circulation now points at the new details.

A short link is also far less data than a full vCard, so the code is lower version and easier to scan. The one cost is the dependency: if the page goes down, the code leads nowhere. You trade offline resilience for the ability to change your mind, and for anything that moves, that trade is worth making.

How ReezoAI generates the code

The vCard QR code generator on this site builds the code entirely in your browser. You fill in the fields you want, the tool assembles the vCard text, and a JavaScript library renders the QR pattern on the page. You choose the error correction level and download the result at a resolution suited to print.

What matters for a contact card is where the work happens. Your name, number, and email are typed into a form, turned into a vCard, and drawn into a code all on your own device. There is no upload, no account required, and no server that receives the contact details you entered. You can confirm this in your browser's developer tools by watching the network tab while you generate: nothing leaves the page. For personal details you are about to hand to strangers at a conference, keeping the data on your machine until you print is the sensible default.

The short version

A vCard QR code is a block of contact text that phones recognize and offer to save. Five fields carry the load without trouble: name, phone, email, organization, and title, with a website URL as a reasonable sixth. Every field beyond those pushes the code to a denser pattern that scans worse on a small printed card. Keep error correction at medium, print at least 2 centimeters wide, and leave the quiet zone intact.

The rule that saves the most grief is knowing when not to use a raw code. If the details never change, bake them in and get a code that works offline forever. If anything might change, encode a link to a contact page instead, and keep the power to edit after the cards are printed.