QR code vCard contact generator: the VCARD spec, field by field

Phones recognise the vCard format by the literal first line BEGIN:VCARD. A working contact looks like this:

BEGIN:VCARD
VERSION:3.0
N:Lopez;Ana;;;
FN:Ana Lopez
ORG:Aldeacode
TITLE:Frontend Engineer
EMAIL:ana@example.com
TEL:+34600111222
END:VCARD

Field by field:

- VERSION declares the spec. Use 3.0 for maximum compatibility, 4.0 is cleaner but iOS Camera still parses 3.0 with fewer surprises in 2026. - N is the structured name: Family;Given;Additional;Prefix;Suffix. The four trailing semicolons in the example are intentional, the field has five components and empty ones must still appear. - FN is the formatted display name, the string the contacts app actually shows. Always include it. - ORG is the organisation, TITLE is the role. - EMAIL and TEL are the channels. You can repeat each one with a type, e.g. TEL;TYPE=CELL:+34600111222, the phone groups them sensibly.

The block ends with END:VCARD on its own line.

The Camera app on iOS and the Pixel and Samsung cameras on Android detect the BEGIN:VCARD prefix and surface an "Add to Contacts" sheet, with every field pre-filled. The user reviews and taps Save. No app, no clipboard.

On older Android the path is the same once a QR scanner runs, the parsing is identical. Browsers like Chrome on iOS that read the camera feed go straight to a download offer for a .vcf file, which the Contacts app then imports.

RFC 6350 says lines end with \r\n (CRLF). Most QR generators emit \n only (LF) and 95 percent of phones still parse it. The five percent are usually older BlackBerry style scanners and a handful of corporate Android builds with strict parsers.

If your QR works on iOS and fails on a partner's older device, regenerate with CRLF. Inside a JavaScript string that means \r\n between every line. If you are pasting into a tool, convert with a unix2dos pass on the source file before encoding.

The vCard 3.0 default charset is UTF-8 in practice, even though the spec is fuzzy. Accents, eñes, Cyrillic, CJK characters all encode fine inside the QR.

The two real failure modes: tools that escape commas inside FN (an FN:Lopez, Ana becomes FN:Lopez\, Ana and the phone shows the literal backslash) and tools that wrap long lines at 75 characters per RFC. Wrapping is allowed but iOS Camera in 2024 builds occasionally chokes. Keep each field on a single line and you avoid both.