vCard Character Limits: What RFC 6350 Actually Requires vs. What Your Contacts App Enforces

RFC 6350, the current vCard specification, does not define a maximum character count for the FN, N, TEL, NOTE, or any other core property. That's a real answer, not an oversight in this post — the spec's authors chose not to cap the content of these fields. What the specification does define, in detail, is something people often mistake for a character limit: a rule about how long a single physical line in the file is allowed to be before it needs to wrap.

Building a vCard and want to see it as a working file first? Clear vCard generates a clean .vcf you can open or download in seconds, with nothing uploaded anywhere.

The 75-Character Rule Is About Lines, Not Content

Section 3.2 of RFC 6350 states that a content line — the raw line of text in the .vcf file, before any word-wrapping a text editor might apply — should be folded once it exceeds 75 characters. Folding means inserting a line break followed by a single space or tab, and the rule for reading a folded vCard back is to treat that break-plus-whitespace sequence as if it were never there. A NOTE field with 400 characters of text doesn't get truncated at 75 characters; it gets split across roughly six physical lines, each starting with a leading space, and reassembled into the full 400-character string the moment a compliant parser reads the file. No content is lost — the 75-character rule is a formatting convention for the file itself, not a ceiling on how much a field can hold.

The specification's actual position is that a name, a note, or a phone number can be as long as the data genuinely requires. The 75-character number that shows up in technical discussions of vCard isn't a limit on content at all — it's a rule about how that content gets wrapped across lines in the raw file.

So Where Do the Real Limits Come From?

They come from the application reading the file, not the format itself. Once a .vcf file is imported into Google Contacts, iCloud, Outlook, or a phone's native contacts app, each of those platforms applies its own practical ceiling — and those ceilings vary, are rarely documented in one place, and have nothing to do with RFC 6350.

Google's own documented limits are the most specific: a field capped at 1,024 characters, a contact capped at 500 fields total, and 128 KB as the overall storage ceiling per contact — with fields silently truncated once that per-field limit is crossed, rather than the import failing outright. That combination is worth noting on its own: RFC 6350 permits an arbitrarily long NOTE field, but Google Contacts will quietly cut it at 1,024 characters without necessarily surfacing a warning that anything was trimmed.

NOTE: The Field With the Widest Gap Between Spec and Practice

The NOTE property is the clearest example of the difference between what the format allows and what actually survives an import. RFC 6350 places no cap on it at all, and it's the field most likely to be used for a long free-text description — a bio, a set of instructions, or background someone wants attached to a contact. In practice, some platforms give NOTE more generous handling than other fields (Google Contacts is reported to allow more in Notes than its standard 1,024-character field cap), while others apply their general internal limits with no special exception. The safest working assumption, absent a documented number for the exact platform in question, is that anything meant to survive across Google, iCloud, and Outlook without silent truncation should stay well under a few hundred characters.

Photos Are a Different Kind of Limit Entirely

A PHOTO field embedded directly in a vCard is typically base64-encoded image data, and base64 encoding inflates a file's size by roughly a third compared to the original binary. That means a photo already close to iCloud's 224 KB cap can cross it purely from encoding overhead, even though the original image file was well within bounds. This is a size limit in bytes, not a character limit in the usual sense discussed elsewhere on this site — but it behaves the same way in practice: cross it, and the platform either rejects the import or drops the field silently.

Why Outlook Is a Special Case

Outlook's limitation isn't about field length at all — it's about the file. Outlook reads and writes only one contact per .vcf file, regardless of how many VCARD blocks the file actually contains. A vCard exported from another platform with multiple contacts bundled into one file will only produce a single contact when opened in Outlook; the rest are silently ignored rather than triggering an error. This is a structural difference in how Outlook parses multi-contact files, unrelated to any character or field-length restriction.

What This Means When Building a vCard

For anyone generating a .vcf file — whether by hand, through a script, or with a tool — the practical takeaway is to design for the strictest real-world consumer, not for what the specification technically permits. Keeping FN, N, and TEL fields concise, and treating NOTE as a field for a short line rather than a long block of text, avoids the silent-truncation problem entirely, since none of it will be visible until the recipient's specific contacts app happens to hit its own ceiling. This same design-for-lowest-common-denominator logic applies directly to a vCard meant to be encoded into a QR code: a vCard kept short and free of embedded photos stays well within both a contacts app's practical limits and a QR code's byte-mode ceiling at the same time. Clear vCard generates a clean .vcf file directly from a simple form, without any of these platform-specific gotchas to manage by hand.

---

The honest summary: RFC 6350 sets no character limit on FN, N, TEL, or NOTE — its only length-related rule is a 75-character line-folding convention that preserves all content while wrapping it across the raw file. The real limits — Google Contacts' 1,024 characters per field, iCloud's 224 KB photo cap, Outlook's one-contact-per-file behavior — come entirely from the applications that import vCards, not from the format itself, and none of them are documented in a single, consistent place.