QR code business cards: build a vCard code you can update without reprinting

Adding a QR code to a business card is the easy decision. The harder, more useful questions are what the code should contain, and whether you can change it after the cards are printed. Get those wrong and you have produced a beautiful reprint trap: five hundred cards with a phone number or job title baked permanently into a pattern of black squares. Get them right and a printed card becomes a living contact that updates itself and tells you how often it is used.

This is a practical guide for agencies producing contact codes, whether for a client's sales team or your own. We will cover what a vCard QR code actually is, the format choice nobody explains, why stuffing everything into the code is a mistake, and the single decision (static or hosted) that determines whether the card can ever change. The recurring theme is the one that runs through every dynamic QR project: the value is in being able to edit the destination, not just encode it.

What a vCard QR code actually is

A vCard QR code is a QR code that carries contact details in the vCard format, so that a phone reading it can offer to save a new contact in one tap. vCard is a real, governed standard: version 3.0 is defined by RFC 2426 (1998) and the current version 4.0 by RFC 6350 (2011), and the data is the same plain text you would find in a .vcf file, served as the MIME type text/vcard.

Inside, a vCard is a short block of labelled fields between BEGIN:VCARD and END:VCARD. The ones that matter for a business card are FN (the formatted display name), N (the structured name split into family, given, and so on), ORG (company), TITLE (job title), TEL, EMAIL, and URL. The standard requires only VERSION and FN, but a card that saves a name with no number or company looks conspicuously empty in the preview, so fill the fields a recipient would actually use.

The important thing to understand is that all of this can live in one of two places: inside the code itself, or on a page the code points to. That distinction is the whole article, and we will come back to it.

vCard or MECARD: the format choice nobody explains

Many QR generators quietly offer a second format called MECARD, and the difference is worth thirty seconds of your attention. MECARD is a compact contact format defined by NTT DoCoMo for Japanese mobile phones. It looks like MECARD:N:Doe,John;TEL:13035551212;EMAIL:john@example.com;; and it is deliberately terse, which makes for a smaller, less dense QR code.

The catch is that MECARD is not a standard. No RFC and no ISO document defines it, it supports fewer fields, and its cross-platform behaviour is less predictable than vCard's. vCard, by contrast, is an IETF standard with broad support for job title, company, multiple numbers, and reliable "add to contacts" behaviour across iOS and Android. Unless you are squeezing a name and one number into the smallest possible code, use vCard.

One more nuance: prefer vCard 3.0 over 4.0 for an encoded code. 4.0 is the newer standard and richer, but phone and camera parsing of 4.0 is still inconsistent, and its longer property syntax uses up more of the code's limited space. Most generators emit 3.0 for exactly this reason. It is the safe default.

Why you should not stuff everything into the code

Here is the technical heart of the matter, and the reason so many home-made contact codes fail to scan. A QR code's data lives in its modules, the little black and white squares, and text like a vCard is stored in what the standard calls byte mode. QR codes come in versions 1 to 40, from a 21 by 21 grid up to 177 by 177, and the more data you encode the higher the version you are forced into, which means more squares packed into the same printed area, each one smaller and harder for a camera to resolve.

The numbers are unforgiving. Error correction, which lets a code survive a scratch or a logo, eats into capacity: the four levels recover roughly 7, 15, 25, and 30 per cent of the code, and choosing a higher level can cut the data a given code holds by more than half. A modest vCard with a name, title, company, two numbers, an email, and a website is already a few hundred characters. Now embed a PHOTO, encoded as base64 text, and you add thousands of bytes, pushing the code into a high, dense version that simply will not scan reliably at the size a business card allows. If you want the deeper version of this, the data capacity guide and the error correction explainer both go further, but the rule for a card is simple: the less you encode, the better it scans.

This is the first real argument for not embedding the contact at all, and instead pointing the code at a page. A short link is a tiny payload. It produces a sparse, robust code that prints small and scans from across a handshake.

The diagram shows the same business card code resolved two different ways, which is the choice the next section is about:

1. The static path: the vCard text is encoded directly into the modules, producing a dense code that is fixed forever and cannot be tracked.
2. The hosted path: the code holds a short link to a contact page, producing a sparse code whose details you can edit and whose scans you can count.

Static or hosted: the choice that decides everything

A static contact code encodes the vCard directly. Its great virtues are independence and permanence: it works entirely offline, depends on no server or provider, and will never suffer link rot. Its fatal flaw for printed cards is that the data is the code. The moment a number changes, a person is promoted, or a company rebrands, every printed card is wrong and the only fix is a reprint.

A hosted contact code points instead at a short URL, and the contact details live on a page you control. This is the same dynamic redirect that sits behind any editable QR campaign: the printed code never changes, but you can repoint or update what it shows whenever you like. Promote someone, change an office number, add a new booking link, and the cards already in wallets and card holders quietly start showing the new details. The page can present an "add to contacts" button that downloads a fresh .vcf, alongside links to a portfolio, calendar, or profile.

The honest tradeoff is that a hosted code depends on that URL staying alive, which means it depends on your provider and your domain. That is a real dependency, and the answer is the same as for any dynamic QR: own the redirect, keep the destination under your control, and treat it as infrastructure rather than a disposable freebie. For most agency work the editability is worth the dependency, because the entire reason to print contact codes at scale is that people and details change. This is the same static versus dynamic decision that governs every other kind of campaign code, applied to contacts.

How a phone actually saves the contact

None of this requires an app, which is the quiet reason QR contact cards work at all. On iPhone, the built-in Camera recognises a vCard or MECARD code and shows a contact banner; tap it and you get the standard "create new contact" or "add to existing contact" flow. On Android, the camera or Google Lens does the same. A static code does this entirely on the device, with no connection needed.

A hosted code reaches the same end by a slightly different route: the contact page's "add to contacts" button serves a .vcf file, and the phone opens it in Contacts exactly as if it had been encoded directly. The recipient cannot tell the difference, but you can, because now you also have a record that the scan happened.

Designing the card so the code actually scans

The destination is most of the battle, but the printed code still has to be readable. A few specifics, drawn from the QR standard and ordinary print practice, cover almost every failure.

• Size. On a business card, keep the code to at least 15 millimetres square, aim for around 20, and 25 is comfortable. The rough rule is that a code should be about a tenth of the distance it will be scanned from, and a card is read at arm's length.
• Quiet zone. ISO/IEC 18004 requires a clear margin of at least four modules around the code. Do not let text or a logo crowd it. Our size and quiet zone guide has the full picture.
• Contrast and colour. Dark code on a light background, with strong contrast. Clever inverted or low-contrast codes are where scannability goes to die.
• File and finish. Supply the printer a vector file, proof it on real stock, and avoid a high-gloss laminate directly over the code, because overhead lights reflect off gloss and defeat the camera. The print preparation guide covers the artwork handoff in detail.

A hosted code helps here too, almost as a side effect: because its payload is just a short link, the code stays sparse and prints cleanly small, where a code stuffed with a full vCard and photo would be dense and fragile.

Measuring what a paper card never could

A static contact code is invisible. Because the phone reads it locally and saves the contact offline, there is no server hit, no log, and no way to know whether a card was ever scanned. For a single freelancer that may not matter. For an agency that has printed contact codes across a client's hundred-person sales team, or onto the badges and collateral for an event, it is a missed measurement.

A hosted contact code routes each scan through the redirect, so every scan is a countable event with a timestamp, an approximate location, and a device type, and you can segment by which batch or which event the card came from. That turns a networking spend into something you can actually report on, in the same way the analytics that matter work for any other code. It is also worth knowing that the same job can be done with an NFC tag instead of a printed code, and many digital business cards offer both.

Counting scans does mean processing some personal data, since identifiers like an IP address count as personal data under GDPR. In practice a plain scan count usually rests on legitimate interest, but if you set cookies or collect more you need a privacy notice and possibly consent. The GDPR guide covers where the line sits; the short version is to anonymise what you can, link a privacy policy from the contact page, and not collect what you do not need.

Common mistakes agencies make

The contact codes that fail tend to fail in the same few ways.

• Embedding a photo or every possible field, producing a dense code that will not scan at card size. Point at a page instead.
• Using a static code for details that will change, which turns the next promotion or office move into a reprint.
• Pointing the code at a PDF or a desktop page rather than a mobile contact page with an obvious "add to contacts" button.
• Printing the code too small or without its quiet zone, or over a glossy finish that reflects.
• Choosing MECARD or vCard 4.0 by accident through a generator's default, and losing fields or compatibility you wanted.

Every one of these is a decision made once, at production, that you live with across the whole print run. That is exactly why the editable, hosted approach is worth the small extra setup.

Frequently asked questions

What is a vCard QR code?

It is a QR code that holds contact details in the vCard standard format, so a phone that scans it can offer to save the contact in one tap. The data can be encoded directly in the code (static) or stored on a page the code links to (hosted), and that choice decides whether you can ever change the details.

Can you edit a QR code business card after it is printed?

Only if it is a hosted, dynamic code. A static code with the vCard encoded into it is fixed forever, so a changed number means a reprint. A hosted code points at a short link to a contact page you can edit, so the printed card keeps working while you update the number, title, or company behind it.

What is the difference between vCard and MECARD?

vCard is an IETF standard (RFC 6350) that supports the full set of contact fields and has reliable cross-platform support. MECARD is a compact format defined by NTT DoCoMo with fewer fields and no formal standard, which makes a smaller code but is less capable. Use vCard unless you genuinely need the tiniest possible code.

Which vCard version should I use for a QR code?

Use vCard 3.0 for an encoded code. Version 4.0 is newer and richer, but phone parsing of it is still inconsistent and its syntax takes up more of the code's limited space. Most generators default to 3.0 for compatibility, and that is the safe choice.

Do QR code business cards work without an app?

Yes. The built-in camera on iPhone and Android (or Google Lens) recognises a vCard or MECARD code and offers to add the contact, with no special app required. A static code does this offline; a hosted code downloads a contact file from its page.

Can a vCard QR code be tracked?

A static one cannot, because the phone reads it locally with no server involved. A hosted contact code routes each scan through a redirect, so you can count scans, see device and rough location, and segment by card batch or event. If you want to measure networking or event ROI, use a hosted code.

What size should a QR code be on a business card?

Keep it at least 15 millimetres square, aim for around 20, and leave the four-module quiet zone clear around it. A sparse code from a short link will print smaller and more reliably than a dense one stuffed with a full vCard and photo.

The short version

A QR code on a business card is only as good as what sits behind it. Encode contact details directly and you get a permanent, untrackable code that becomes wrong the day a number changes. Point the code at a short link to a hosted contact page and you get a sparse, reliable code you can edit without reprinting and whose scans you can actually measure. Use vCard 3.0 over MECARD or 4.0, keep the payload small so the code stays scannable at card size, leave the quiet zone clear, and proof it on real stock. Then treat the card not as a finished object but as a pointer you control: when the details change, you change the page, and every card already in the wild updates itself.