vCard QR code generator
100% Private & Local — Your data never leaves your browser. These QR codes are permanent and will never expire.
Contact card settings
Design
Add a centre logo
The image is read in this page and embedded in the code as a data: URL. It is not uploaded, and it stays inside the file you download.
More design options
The dark half of the code. Keep it well below the background in lightness.
Covers the quiet zone as well as the gaps between modules. A transparent background leaves it out of the file, so nothing is drawn with it.
Contrast 11.5:1 between the modules and the background.
PNG and WebP keep an alpha channel; the SVG simply omits the background rectangle. Whatever the code is placed on becomes the light half of the contrast.
A gradient fills the dark modules only. Its lighter end sets the contrast a scanner actually gets, so both ends have to stay dark.
The second colour, used only while a gradient is selected. It is measured for contrast alongside the first.
Degrees clockwise from a left-to-right sweep. A radial gradient spreads from the centre outwards, so the angle applies to a linear one only.
Rounded shapes cover less of each cell. The centre stays covered, which is where a decoder samples, but a small print of a dense code reads more reliably as squares.
The ring of the three finder patterns.
The eye inside each finder pattern.
The blank margin around the code, measured in modules. 4 is the specified minimum.
Higher recovery survives more damage and costs capacity, so the same content produces a denser symbol.
A logo sits at the centre and holds the level at H. Its width limit follows the symbol: 14% on the smallest code, 30% on a dense one.
Live preview & export
Enter a first or last name. A vCard has to carry a display name, so a card with neither is not a valid record.
Export
Raster, for screens
Complete the form to enable the downloads.
Export size and encoded text
- Payload
- Nothing encoded yet
- Symbol
- Not built yet
- Recovery
- M
Waiting for input
A vCard QR code carries a complete contact record, so scanning it offers to save a contact instead of opening a page. Every field you fill adds bytes and the symbol grows with them, which is why a full card has to be printed larger than a plain link.
When someone scans it
The phone shows a contact preview and offers to add it to the address book. No page loads and nothing is downloaded.
What a vCard 4.0 record looks like
The payload is a small plain-text document, not a link. It opens with BEGIN:VCARD and VERSION:4.0, carries one property per line separated by carriage return and line feed, and closes with END:VCARD. Version 4.0 is defined by RFC 6350.
Two properties cover the name and they do different jobs. N holds the structured name in five ordered slots, family name first. FN holds the single display string the address book shows, and RFC 6350 makes FN mandatory, which is why a card with no name at all is not a valid record.
ADR is one property with seven components in a fixed order, and empty ones still need their separators. That is why an address with no post office box begins with two semicolons before the street.
- N:Okonkwo;Amara;;; then FN:Amara Okonkwo
- ORG:Northgate Bindery and TITLE:Head of production
- TEL;TYPE=cell:+447700900123 and TEL;TYPE=work,voice:+442079460812
- ADR;TYPE=work:;;18 Cannon Row;Bristol;Somerset;BS1 4RN;United Kingdom
- RFC 6350 types TEL as a tel: URI; the shorter bare-number form used here is also what 3.0-era parsers expect
Why a contact card makes a large symbol
A card that fills every field on this page runs to roughly 400 bytes of text, several times a typical web link. Level H spends about two thirds of a symbol's codewords on error correction — 2,430 of 3,706 at version 40 — and that is what buys the roughly 30 per cent of the symbol it can restore. It also makes H the level that stores the least: a version 20 grid holds 382 bytes at H. That is why the default here is M, which puts the same information on a noticeably smaller grid.
Version 20 is 97 modules across. With the four-module quiet zone the standard requires on each side, that is 105 modules edge to edge. Printed 25 mm wide, each module is about 0.24 mm. Print guidance puts the floor between 0.4 and 0.5 mm per module, so those 105 module widths want somewhere between 42 and 53 mm, and a full contact card at 25 mm is well under either figure.
If the code has to be small, the fix is fewer bytes rather than more recovery. Dropping the note, the second phone number and the region often takes a hundred bytes out of the payload and pulls the version down several steps.
- Accented and non-Latin characters are encoded as UTF-8, costing two to four bytes each instead of one
- A centre logo forces level H, so a full card plus a logo needs the larger print size
- The absolute ceiling for one symbol is 2,953 bytes, at level L
Version 4.0 and what still reads it
There are three vCard versions in circulation: 2.1, 3.0 from RFC 2426, and 4.0 from RFC 6350. This page writes 4.0, which is the current specification and the one that defines UTF-8 as the encoding rather than leaving character sets to a parameter.
iOS Contacts and current Android contact apps read 4.0 records from a scan. Support is not universal below that: some older third-party contacts apps and some enterprise address books were built against 2.1 or 3.0 and will either ignore properties they do not recognise or refuse the record outright. If a card has to reach a fleet of old handsets, test one before printing a thousand.
Nothing about the record is verified. A vCard states whatever you typed, so a scan is an offer to save a contact, not proof the contact is genuine. Every platform shows a confirmation screen before writing to the address book.
Questions and answers
How much can I put on one card before it stops scanning?
The limit is print size, not the format. A full card is around 400 bytes, which at level M lands on a grid of roughly 77 to 85 modules. Printed at 45 mm or wider it scans from arm's length; printed at 25 mm the modules fall to about 0.24 mm and phone cameras start to miss it.
Why version 4.0 rather than 3.0?
4.0 is the current specification, RFC 6350, and it fixes character encoding at UTF-8 so accented names and non-Latin scripts survive the round trip without a charset parameter. The trade-off is that a few old contact apps built for 2.1 or 3.0 may drop properties they do not recognise.
Can I include a photo on the card?
Not embedded. A PHOTO property carries the image as base64, and even a small headshot runs to tens of kilobytes against a hard ceiling of 2,953 bytes for a whole symbol. Put the image on a page of your own and use the Website field instead.
What happens to accented characters and non-Latin scripts?
They are encoded as UTF-8 and stored in the QR code's byte mode. They work, but they are not free: a character outside plain ASCII costs two to four bytes rather than one, so a name in Greek, Arabic or Japanese pushes the symbol up a version or two.
How a static QR code works
Every code on this site is static: the payload is written into the black and white modules themselves. Nothing is looked up when the code is read, no server of ours takes part, and no subscription holds the printed code up. The same property is the limit — once it is printed, what it contains cannot be changed.
Three things then decide whether a printed code reads: how many bytes the payload came to, which recovery level absorbs the damage, and how wide a single module ends up on paper. These guides work through each of them with the numbers.