Which vCard versions are supported?

The validator handles vCard 2.1, 3.0 and 4.0. It reads the VERSION property of each card and applies the rules for that version — for example, FN is mandatory in 3.0 and 4.0, while N is mandatory in 2.1.

What counts as an error versus a warning?

Errors are violations that can break a compliant import, such as a missing VERSION, a missing mandatory FN or END:VCARD. Warnings flag things that usually work but are technically off-spec, like a short N value or version-mismatched encoding. Info notes are non-standard or unknown properties.

Why does it flag ENCODING=QUOTED-PRINTABLE?

Quoted-printable encoding is valid in vCard 2.1 but was removed in vCard 4.0, which uses plain UTF-8 text. If a 4.0 card declares quoted-printable encoding, many parsers will mis-decode accented characters, so the tool reports it as an error for that version.

Does it validate multiple contacts at once?

Yes. A VCF file exported from a phone often contains many VCARD blocks back to back. Each block is validated independently and gets its own report, with a summary of total errors and warnings across the file.

Is my contact data uploaded?

No. Parsing and validation run entirely in your browser. None of your contact data is sent to or stored on a server, which makes it safe to check sensitive address books.

vCard Validator — Gera Tools

A vCard (.vcf) is the standard text format for exchanging contact details, defined across three spec versions: 2.1, RFC 2426 (3.0) and RFC 6350 (4.0). Small format mistakes — a missing VERSION, an FN property that’s required but absent, or an encoding label that’s valid in one version but not another — can cause contacts to import partially or with garbled characters. This validator checks a card against the rules for its declared version so you can catch those problems before a bulk import.

How it works

The validator first unfolds the file: per the spec, a line beginning with a space or tab is a continuation of the previous line, so those are joined back together. It then splits the text into individual BEGIN:VCARD … END:VCARD blocks and validates each one.

For every card it checks:

Structure — a matching BEGIN:VCARD and END:VCARD, and a valid VERSION of 2.1, 3.0 or 4.0.
Mandatory properties — FN (formatted name) is required in 3.0 and 4.0; N (structured name) is required in 2.1. Each property line must contain a : separating name from value.
Structured values — N should have five semicolon-separated components (Family, Given, Additional, Prefix, Suffix); EMAIL should look like an address; TEL should contain digits.
Encoding and type labels — ENCODING=QUOTED-PRINTABLE is rejected for 4.0, and bare type tokens like ;HOME (2.1 style) are flagged when a 4.0 card should use TYPE=home.

Properties that aren’t part of the standard and aren’t prefixed with X- are reported as info-level notes rather than errors.

Reading the results

Each card is summarised with its version, name and property count, followed by a colour-coded list:

Error (red) — blocks compliant import; fix before exporting.
Warning (amber) — usually imports but is off-spec or risks interoperability problems.
Info (grey) — non-standard or unknown properties, shown for awareness.

Tips

If accented names come through as =C3=A9-style sequences, the source was quoted-printable encoded — fine for 2.1 but a problem if the card claims to be 4.0. If a phone export won’t import cleanly elsewhere, validate it here first: a missing VERSION or unterminated card is the most common culprit. All checks run in your browser, so even sensitive address books stay on your device.