vCard Contact QR Code Generator

Two text conventions carry contact details inside a QR code: MECARD, a compact convention with a short list of fields, and vCard, the format address books exchange contacts in. This generator emits vCard 3.0 as specified in RFC 2426 — chosen over MECARD for broader field support and better scanner coverage. The specification sources behind every builder on this site were verified against the live documents on 2026-07-20, and the vCard builder is tested against independently constructed reference strings, including hostile inputs such as names with commas and backslashes.

The price of the richer format is length. A vCard payload is longer than a link, so the symbol has more modules, and that is the one fact about contact codes worth understanding before printing one. The sections below show exactly what the generator writes, line by line, how the escaping rules protect punctuation, and how payload length becomes the version and module count printed under each example.

Guide: vCard contact QR codes covers the convention, its escaping rules and more engine-built cards in depth. The guides index has the rest of the series.

The builder writes one content line per field, in a fixed order, and only for the fields you filled in. The smallest card it will produce needs a first or a last name; with neither, the form reports "Enter at least a first or last name." The firms, numbers and addresses in every card on this page are invented; the worked example above borrows a historical name as a placeholder, with an invented firm, an example.com address and a reserved-range number. A card for Mira Quill with nothing else filled in is 5 lines:

• BEGIN:VCARD and END:VCARD bracket the card, and VERSION:3.0 declares which edition of the format the lines between them follow.
• N is the structured name. Its components are separated by semicolons in the order RFC 2426 fixes — family name, then given name, then three components (additional names, honorific prefixes, honorific suffixes) that this generator leaves empty. That is why a name-only card still shows a run of semicolons: the empty components are part of the format, not a defect.
• FN is the formatted name: the first and last name joined by a space, or whichever one of them you entered.
• TEL;TYPE=CELL carries the phone number, labelled as a mobile number, after normalization to E.164 — the plus-prefixed international form that the tel: URI scheme (RFC 3966) uses. Spaces, dots, dashes and parentheses are accepted and removed, a leading 00 is accepted as an alias for +, and a number without a country code is refused rather than guessed. The 7-field card below was typed as +44 20 7946 0123 and is stored as TEL;TYPE=CELL:+442079460123.
• EMAIL is checked for the shape of an address — something, an @, something, a dot, something — and then escaped like any other text value.
• ORG and TITLE are escaped text values; the next section shows what the escaping does to them.
• URL passes through the same validation as the URL generator: the protocol must be present and must be http or https. It is then written as the trimmed text, unchanged — never wrapped in a shortener or tracking redirect.

Every line, including the last, ends with the two-character CRLF sequence the standard requires (RFC 2426 §2.4.2). The line endings are invisible in the boxes on this page but are part of the payload: the name-only card is 69 characters long, of which 10 are line endings. A card with all 7 fields filled in — the most this generator can carry — looks like this:

RFC 2426 reserves four things inside a text value: the backslash, the semicolon, the comma and the line break. The semicolon is the component separator visible in the N line, so a surname containing one would otherwise be read as a component break; the comma and the backslash are reserved by the format in the same way. The builder's escaping helper prefixes each of the three characters with a backslash and flattens a line break into the two characters \n. Three demonstrations, each computed by that helper when this page was built:

• A company typed as Quill, Fern & Sons; Ltd is written as Quill\, Fern & Sons\; Ltd.
• A value typed with a literal backslash, Finance\Audit; Ltd, becomes Finance\\Audit\; Ltd. The backslash is doubled first, and only then is the semicolon escaped, so a reader unescaping the line gets back exactly what was typed instead of a mangled sequence. That ordering is locked by a test.
• A value containing a line break, Floor 2↵North wing (↵ marks the line break typed into the field), is flattened to Floor 2\nNorth wing — a backslash and the letter n, not an actual newline, so the one-line-per-field structure of the card survives whatever is pasted in.

Applied to a card, the escaping lands in the ORG and TITLE lines. A partner at an invented, heavily punctuated firm encodes as:

Nothing is escaped in the URL line, because a URL has its own encoding rules and has already been validated as one, and nothing in the phone line can need escaping once E.164 normalization has reduced it to a plus sign and digits. The escaping exists so that punctuation in a name or a company cannot corrupt the card. Scan a test print and read what the phone shows.

Under each example is a line of symbol facts. They come from the encoder, not from this page: the payload is handed to the vendored reference encoder, which chooses the smallest QR version that holds it at the requested error-correction level, and the page prints what came back. The interactive generator above runs the same engine, so the facts it shows for your own card are produced the same way.

• Version is the symbol's size class, the encoder's choice from the versions it numbers 1 to 40. The engine's model documents the side length as a constant plus a fixed number of modules per version, and this page's build asserts that every card on it obeys that rule. Read off the cards here, the constant is 17 and each step up in version adds 4 modules to the width and to the height: for the name-only card, 17 + 4 × 5 = 37; for the 7-field card, 17 + 4 × 10 = 57.
• Modules is that side length, excluding the quiet zone. Every download adds 4 modules of white on each side on top of it.
• Error correction is the level actually encoded. The examples on this page request level M, the generator's default without a logo; the reference encoder raises the level when a higher one fits in the same version without growing the symbol, so an example can report Q or H although M was requested. The level is never lower than requested.

The table is ordered by payload length, and the mechanism is visible reading down it: each extra field lengthens the payload, and a longer payload needs at least as high a version — more, and therefore smaller, modules at any given print size. The name-only card is version 5; the 7-field card is version 10, 57 modules on a side against 37. There is nothing to look up: enter the fields and the generator reports the version for exactly what you typed.

The PNG download offers 3 pixel sizes, and the generator labels each with its printed size at 300 DPI — pixels divided by 300 gives inches, and inches times the millimetres in an inch gives millimetres:

• 512 px — 1.71 in × 1.71 in (43.3 mm × 43.3 mm) at 300 DPI
• 1024 px — 3.41 in × 3.41 in (86.7 mm × 86.7 mm) at 300 DPI
• 2048 px — 6.83 in × 6.83 in (173.4 mm × 173.4 mm) at 300 DPI

The preset changes the number of pixels, not the number of modules. The exporter spreads the symbol's modules, plus the quiet zone, across the chosen width, placing module edges on rounded pixel boundaries so that adjacent modules never leave antialiasing seams. Dividing the printed width by the total module count gives the average module pitch, which is where payload length shows up on paper:

Same preset, same printed width — the fuller card simply spends that width on more modules. That is the whole of the "fill in only the fields you need" advice: every optional field you leave empty keeps the payload shorter, and a shorter payload never needs a higher version, so its modules are at least as large at the same size. What this page will not give you is a minimum size. The methodology is explicit that error correction helps a damaged code scan but print size and contrast still matter, and that a freshly generated code is untested until a real device has scanned it. Print one, scan it, then print the rest.

The SVG download is the same symbol as a single vector path with the module size as its scale factor, so it scales without pixelation and keeps module edges crisp at any output size. It includes the quiet zone, like the PNG.

The builder validates format, not truth. It can tell that a phone number has a country code and a plausible number of digits, that an email address has the shape of one, and that a URL has a protocol — and nothing more. It cannot know whether the number is reachable, whether the mailbox exists, whether the URL is safe, or whether the job title is still current. A number with two digits transposed encodes perfectly, scans perfectly, and saves a contact nobody can reach. Check each field against its source before printing, because the only way to find such a mistake afterwards is to scan the card and read what comes up.

The code is static: the contact details live in the image, with no redirect through our servers. That is why it never expires and cannot be held hostage — and also why it cannot be edited after printing and scans cannot be counted. A changed number means a new code, and the old printed cards keep handing out the old number for as long as they circulate.

The code itself cannot write to a contacts list — it carries text and nothing more, and saving that text is the scanning person's action, not the code's.

• Cropping the quiet zone. The 4-module white border is part of the symbol as the standard defines it. The renderer always draws it and offers no way to disable it; trimming it away in a layout program is the most common self-inflicted scan failure.
• Inverting the colours. The style panel computes the contrast of your colour pair with the WCAG relative-luminance formula and warns below 4.5:1. It warns separately for light-on-dark (inverted) codes, which many scanners reject, however high the ratio.
• Expecting a wrong number to fail. The card encodes whatever was typed. Format is checked; truth is not. A code that scans is not evidence that its contents are right.
• Treating the logo as part of the contact. The optional logo in the style panel is drawn over the symbol, not written into the vCard. Adding one forces error correction H and is capped at 16% of the symbol area — a cap set by decode-testing a worst-case logo in the round-trip suite, not derived from the theoretical recovery ceiling of level H.
• Expecting a larger PNG to be a different code. It is the same symbol at a larger module pitch; the version and the module count are fixed by the payload, as the tables above show.
• Sharing the card as a message. The WhatsApp share in the delivery row sends text, and the engine's share plan for a vCard payload is a note rather than a link — a fact this page checks at build time. The note reads: "WhatsApp sharing sends text, not images — and this code’s content is not a link, so pasting it into a chat would be meaningless. Download the PNG and attach it in WhatsApp instead."

Pair the card with a WhatsApp chat code or a plain phone call code for single-action alternatives, or an email code for a pre-addressed message.