vCard QR code saves a truncated contact

A scan never truncates: generation does

Start with the fact that narrows the search: Reed–Solomon decoding is all-or-nothing. A QR code either yields its complete payload or fails entirely; there is no partial read. So when a saved contact is missing the second half of a note, or the address stops mid-street, the payload itself was already cut before the code was rendered.

That leaves exactly three suspects:

1. A generator field cap. Many web generators silently limit field lengths or total payload size and truncate what you typed, no error, just a shorter vCard.
2. A density-driven trim. Some tools cap the QR version they will emit and cut the payload to fit, again silently.
3. The address book dropped whole fields on import. That is a different failure with different fixes (unescaped punctuation, missing FN, version mismatches) covered in vCard imports with wrong fields. Rule of thumb: values cut mid-word point at generation; whole properties vanishing points at import.

Decode your printed code with our scanner and read the raw text. If the vCard is already incomplete in the payload, you have confirmed a generation cut.

Why generators cut: the density maths

A vCard is verbose, and every byte raises the QR version. Byte counts below are typical for the listed content, with the version each needs at error correction level M (see the full capacity table):

Contact content	Payload	Version (EC M)	Grid
Name, one phone	~100 bytes	6	41×41
Name, org, title, 2 phones, 2 emails, URL	~300 bytes	13	69×69
Plus address, note, photo URL, socials	~650 bytes	20	97×97
Everything, generously filled	~1,000 bytes	26	121×121

A version 20+ code has modules so small at business-card size that it is too dense to scan reliably, a 2 cm print of a 97×97 grid gives modules of about 0.19 mm, well under the 0.4 mm print floor. Generators know this, which is why some quietly cut. The honest ones error instead.

The fixes

Trim to the fields that earn their bytes. Name, one phone, one email, one URL. Drop the note, the photo URL and the social links, the photo and socials are the heaviest fields and the least likely to survive import anyway. A MeCard encodes the same core fields in roughly 30–40% fewer bytes if you need the smallest possible code.

Or stop encoding the contact at all. Encode a short URL to a hosted contact page with a .vcf download link. The payload drops to ~30 bytes (a version 2–3 code), and the contact can be as rich as you like, updated after printing, and identical for every format of card. This is the right answer for any contact that will not fit version 13 or so.

Then rebuild without caps. UseQR's vCard generator builds the full RFC 6350 payload from what you enter. Nothing is silently dropped or shortened; the builder folds lines at 75 octets and escapes punctuation per the spec. Verify the result by decoding it and reading every field back before you print.

FAQ

Why is my vCard QR code contact cut off?

Because the payload was cut before the code was generated, a scan cannot truncate; it either returns everything or fails. Some generators silently cap field lengths or total size. Decode the code and read the raw vCard to confirm where the cut happened.

How much contact information fits in a QR code?

The hard ceiling is 2,953 bytes, but the practical limit is far lower: around 300 bytes (a name, organisation, two phones, two emails and a URL) keeps the code at version 13 and printable at business-card size.

Should I use a vCard QR code or a link to a contact page?

For a few core fields, a direct vCard works offline and saves in one tap. For a rich contact (photo, address, socials) encode a short URL to a hosted page with a .vcf download; the code stays small and the details stay editable.

Is MeCard smaller than vCard?

Yes, typically 30–40% smaller for the same core fields, because its syntax is terser. It supports fewer field types, so it suits name-phone-email codes; anything richer needs vCard or the URL-to-contact-page pattern.