VCF Encoding Fix — Why Your Contacts Show García and How to Repair the File

Symptom table

Look at the raw .vcf in Notepad, TextEdit or VS Code before you blame the phone. The garbage you see is a fingerprint. Match it, then pick the fix — do not run every repair “just in case,” because the wrong one (decoding UTF-8 a second time, or saving UTF-16) makes the next importer worse.

Two of those (García, Garc=C3=ADa) often mean the file is already recoverable in the browser. Replacement characters and UTF-16 mean the bytes on disk are the wrong encoding — you have to change them in an editor before this site will see the real name. A UTF-8 BOM is stripped by file.text(), so the viewer still finds BEGIN:VCARD; some phone importers, as of 2026, do not.

vCard 2.1 quoted-printable

How it looks. Open the file as text and the name line is not N:García;Ana;;;. It is:

N;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:Garc=C3=ADa;Ana;;;
FN;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:Ana Garc=C3=ADa

Long notes may break in the middle of a word with a trailing = and the next line not indented — that is a 2.1 quoted-printable soft break, not a second property.

Why. vCard 2.1 predates “just write UTF-8.” Old Nokia and Samsung feature phones, SIM-management tools and a long tail of “export to phone” utilities wrote every non-ASCII character as =XX byte escapes and labelled the line CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE. A text editor does not decode that. A vCard 2.1 parser should. Google Contacts, iCloud and most current Android / iPhone importers usually do, as of 2026. Some car head units, old Outlook builds and a few manufacturer Contacts apps still show the equals-signs.

This site's field parser — the one behind Open a VCF file, the VCF editor and VCF to CSV — detects ENCODING=QUOTED-PRINTABLE (and the bare QUOTED-PRINTABLE token), joins those soft breaks, and decodes the bytes as UTF-8. A 2.1 round-trip in the test suite restores María from =C3=AD. The CHARSET parameter is not read on that path.

Fix. If the viewer already shows García, the file is readable; the importer is not. Convert it to vCard 3.0 so the name is stored as UTF-8 with no encoding parameters. Use the VCF editor: load the file, set the version select to 3.0 (a 2.1 source defaults back to 2.1, which would write quoted-printable again), and download. That download is UTF-8 3.0 without =C3=AD. It also drops photos and custom fields — read the warning on that page before you rely on it. A property-level 2.1→3.0 rewrite in this codebase goes further: it decodes quoted-printable, honours CHARSET=ISO-8859-1 / LATIN-1 by reading those bytes as Latin-1 (Caf=E9 becomes Café), decodes any other CHARSET as UTF-8, writes a plain N:García line, keeps PHOTO payloads, X- fields and item groups, and synthesizes FN from N when 3.0 or 4.0 would otherwise lack it. That rewrite is the version converter on this site — use it when you need 2.1→3.0 without dropping photos.

CHARSET says one thing, bytes are another

How it looks. The line claims CHARSET=ISO-8859-1 but the quoted-printable payload is =C3=A9 (UTF-8 for é), or it claims CHARSET=UTF-8 and the payload is =E9 (Latin-1 for é). Windows address-book exports from the 2000s do this constantly. The label and the bytes disagree, so one of the two readers — “trust CHARSET” or “always UTF-8” — will get the name wrong.

Why. vCard 2.1 let every property declare its own CHARSET. Exporters copied a template (ISO-8859-1 was the Western European default) and then wrote UTF-8 bytes anyway, or the other way around. There is no checksum. The importer has to guess.

What this site's parser does — said plainly. It reads quoted-printable as UTF-8. It ignores CHARSET. decodeQuotedPrintable collects =XX bytes and runs them through a UTF-8 decoder. There is no branch on CHARSET=ISO-8859-1. That is a deliberate choice: the files this site is built for (Google, iCloud, modern Android / iPhone, and this site's own 2.1 generator, which always labels CHARSET=UTF-8) are UTF-8 under the escapes. It is also why a genuine Latin-1 card from a very old handset can show the wrong accents in the viewer, editor and VCF to CSV.

Fix. If the viewer already shows the right name, the bytes were UTF-8 and the CHARSET label was the lie — convert to 3.0 in the editor and the label goes away with the encoding parameters. If the viewer shows the wrong accents on a quoted-printable line labelled CHARSET=ISO-8859-1 (Caf=E9), do not re-save as UTF-8 in a text editor: the payload is already ASCII escapes. Use the version converter, which honours CHARSET=ISO-8859-1 / LATIN-1 / LATIN1 on quoted-printable values. The editor, viewer and spreadsheet export do not. Raw Latin-1 files with no quoted-printable are the ANSI case below.

The file was saved as ANSI

How it looks. García becomes Garc?a, Garc�a or Garc□a in the viewer, and in a hex editor the í is a single byte (0xED or 0xE9), not the two UTF-8 bytes C3 AD. There is usually no BOM. The VERSION line may still say 3.0 — ANSI is a file encoding, not a vCard version.

Why. Classic Outlook for Windows, old Notepad, and a pile of “CSV to vCard” desktop utilities write the system ANSI code page — on a US or Western European machine that is Windows-1252, which is Latin-1 plus a few extra characters. Nothing in the first bytes announces that. Every tool on this site reads a dropped .vcf with file.text(), which always decodes as UTF-8. A 0xE9 é is invalid UTF-8, so it becomes a replacement character. The converter does not sniff ANSI and does not fall back to Windows-1252. The same rule is documented on the Outlook CSV path.

Fix. As of 2026: open the .vcf in Notepad → File → Save As → Encoding: UTF-8 (on recent Windows, pick “UTF-8” not “UTF-8 with BOM” if both appear). In VS Code: click the encoding in the status bar → “Save with encoding” → UTF-8. Then drop the saved file on the viewer to confirm García is García, and re-save as 3.0 from the editor if you still need a clean vCard. Do not skip the re-save: feeding ANSI bytes to this site will not magically produce é.

BOM and UTF-16

How it looks. The first visible characters of the file, in a Latin-1 view, are BEGIN:VCARD. That is the UTF-8 BOM (EF BB BF) sitting in front of BEGIN. A UTF-16 export from Excel or an older Windows “Unicode text” save looks different again: a hex dump starts FF FE or FE FF, Notepad may show spaces or boxes between every letter (BEGIN as B E G I N), and this site's viewer will not find a vCard at all.

Why. Excel “Unicode Text” and some Windows “Save as Unicode” paths write UTF-16, as of 2026. Notepad’s “UTF-8” choice on older Windows was UTF-8 with BOM. vCard is specified as text; 3.0 and 4.0 assume UTF-8. parseVcf does not strip a leading U+FEFF, so a BOM that survives into the string makes the first property \uFEFFBEGIN instead of BEGIN, and the first card never starts. Dropped files go through file.text()first, which decodes as UTF-8 and strips a UTF-8 BOM, so this site's viewer still finds BEGIN:VCARD. UTF-16 is worse: file.text() does not detect UTF-16, so the bytes become replacement characters and NULs and parseVcf returns no cards. Phone importers, as of 2026, almost never transcode UTF-16 either.

Fix. As of 2026: re-save as UTF-8 without a BOM. In VS Code: status-bar encoding → “Save with encoding” → UTF-8 (not UTF-8 with BOM, not UTF-16 LE). In Notepad on current Windows, pick UTF-8. A UTF-8-with-BOM file already opens here; UTF-16 does not. Then confirm in the viewer that the first line is a plain BEGIN:VCARD and the names are readable. Do not import a UTF-16 .vcf into iPhone or Android and hope; as of 2026 they almost never swallow it.

Check what you actually have

Before you rewrite anything, look. Drop the file on Open a VCF file. That page is a viewer, not an importer: it parses every BEGIN:VCARD block in the tab and shows names, phones and emails. It uses the same parseVcf path as the editor and VCF to CSV, including the 2.1 quoted-printable decode (always UTF-8, CHARSET ignored).

If names look right there, the file is fine — UTF-8, or quoted-printable that decoded as UTF-8. The phone's importer is the problem. Do not hex-edit the file. Convert to 3.0 and import the new copy; or import via Google Contacts / iCloud on the web, which as of 2026 are less fussy than some on-device Contacts apps.

If names look wrong there, the bytes are ANSI or Latin-1 (including Latin-1 quoted-printable whose CHARSET this parser ignores). If the viewer finds no cards, suspect UTF-16. Fix the file encoding first, then come back. To inspect a large dump as rows — first name, last name, two phones, two emails — use VCF to CSV and open the spreadsheet. The CSV is UTF-8 with a BOM so Excel shows accents; that BOM is for Excel, not for the vCard you will import later.

Re-save clean

Once the viewer shows the right names, the remaining job is a file a fussy importer will accept: vCard 3.0, UTF-8, no quoted-printable, no CHARSET parameter, no UTF-16, no BOM on the vCard itself. That is what the VCF editor writes when you load the file, set the version to 3.0, and download. The download is a JavaScript string packed as text/vcard;charset=utf-8. For 3.0 the generator writes UTF-8 directly — María stays María, with no =C3=AD.

Two catches. First: if the original file was 2.1, the version select defaults to 2.1, and a 2.1 download will put quoted-printable right back in. Switch it to 3.0. Second: re-save runs the same generator as the VCF creator. It writes BEGIN, VERSION, N, FN, ORG, TITLE, TEL, EMAIL, ADR, URL, NOTE and END. It does not write PHOTO, LOGO, BDAY or any X- property. A third phone or email per contact is dropped. That is the warning on the editor page — read it there before you throw away the original .vcf. If you need the photos, keep the original as the archive and only import the cleaned copy for the names.

After the download, check it once in the viewer. Then import. If the destination still garbles the name, you now know it is the importer, not the file: try Google Contacts or iCloud as the middle step, or a different app on the phone. The vCard format reference and what is a VCF file cover the VERSION / CHARSET / folding rules this page has been using as a repair checklist.

VCF encoding fix — FAQ

• Why does iPhone show é as é in a vCard?

  The UTF-8 bytes for é are C3 A9. If Mail, Files or the Contacts importer (as of 2026) reads those bytes as Latin-1 or Windows-1252, you see é (or García for García). The file is often already UTF-8 and the reader guessed the wrong charset. Open it in the VCF viewer on this site: if the name looks right there, the file is fine and iOS is the problem — re-save as vCard 3.0 UTF-8 in the editor and import that copy. If the name looks wrong in the viewer too, the file itself is mis-encoded; fix the bytes before you import.

• Can I fix a garbled VCF without a text editor?

  Yes, when the names already decode as UTF-8 — including vCard 2.1 quoted-printable that this site's parser turns back into García. Drop the file on the VCF editor, set the version to 3.0, and download. That writes UTF-8 with no quoted-printable. If the file is true Latin-1 or Windows ANSI, you still need a text editor first (as of 2026: Notepad Save As UTF-8, or VS Code “Save with encoding”). The viewer, editor and VCF to CSV do not transcode Latin-1 automatically.

• Does this site fix Latin-1 encoding automatically?

  No. The parser used by the viewer, the editor and VCF to CSV decodes quoted-printable as UTF-8 and ignores the CHARSET parameter. A CHARSET=ISO-8859-1 line whose payload is Latin-1 (Caf=E9 for Café) will show the wrong accents in those tools. Re-saving the .vcf as UTF-8 in a text editor does not decode those escapes — they are already ASCII. The VCF version converter honours CHARSET=ISO-8859-1 / LATIN-1 / LATIN1 on quoted-printable and turns Caf=E9 into Café. A whole file stored as Latin-1 without quoted-printable is the ANSI case: re-save as UTF-8 first.

• Which vCard version avoids encoding problems?

  vCard 3.0. UTF-8 is native: no CHARSET parameter, no ENCODING=QUOTED-PRINTABLE, accents sit in the line as themselves. vCard 4.0 is the same on encoding. vCard 2.1 is the version that invented CHARSET plus quoted-printable, which is why old Nokia, Samsung and SIM exports look like =C3=AD in a text editor. Default to 3.0 unless a specific old device demands 2.1.

• Android imported my contacts with garbled names. What now?

  Same four causes as everywhere else. Open the .vcf in the viewer on this site first. If names look right there, the file is UTF-8 (or quoted-printable that decoded as UTF-8) and the phone’s importer is at fault — convert to vCard 3.0 in the editor and, as of 2026, import via Google Contacts on the web rather than a manufacturer Contacts app. If names look wrong in the viewer, the bytes are ANSI or Latin-1 (including Latin-1 quoted-printable whose CHARSET this parser ignores). UTF-16 usually yields no cards at all. Re-save as UTF-8 without a BOM, then convert.

• Outlook exported my contacts as ANSI. How do I fix the VCF?

  Classic Outlook for Windows often writes the system ANSI code page (usually Windows-1252), with no BOM to warn you. This site reads a dropped .vcf with file.text(), which always decodes as UTF-8, so a 0xE9 é becomes a replacement character. As of 2026: open the file in Notepad → Save As → Encoding: UTF-8 (or VS Code “Save with encoding” → UTF-8), then drop it on the editor or VCF to CSV. Outlook.com / new Outlook exports are more often already UTF-8.

• What is quoted-printable in a vCard?

  An encoding that writes each non-ASCII byte as an equals sign plus two hex digits. vCard 2.1 uses it with CHARSET=UTF-8, so the í in García becomes =C3=AD and the line looks like N;CHARSET=UTF-8;ENCODING=QUOTED-PRINTABLE:Garc=C3=ADa;…. A text editor shows the escapes; a parser that understands 2.1 decodes them. This site’s field parser (viewer, editor, VCF to CSV) does that, always as UTF-8, including the soft line breaks that end in a lone =. It does not read CHARSET. The version converter is the exception: it honours CHARSET=ISO-8859-1 on quoted-printable.