When you import a VCF file and contacts appear with missing photos, birthdays, addresses, or notes, the import itself succeeded but the receiving platform silently stripped fields it does not support or could not parse. Google Contacts drops contact groups. iCloud rejects photos over 224 KB. Outlook ignores X-properties. The fix: check which fields are in your VCF file (open in a text editor), then normalize the file for the target platform before importing. A VCF converter tool or the Google Contacts re-export method handles most field mapping issues automatically.
Introduction
You import a VCF file and the import completes without errors. You open your contact list expecting to see everything: names, phone numbers, email addresses, photos, birthdays, postal addresses, and notes. But some fields are simply gone. Photos are missing. Birthdays did not come through. Address fields are empty. Notes vanished. The frustrating part is that no error message warned you about the data loss.
This happens because every contact platform supports a different subset of vCard properties. A VCF file can contain dozens of field types, but the receiving application may only understand a fraction of them. Fields that the platform does not recognize get silently dropped during import rather than triggering an error. The result is a contact list that looks complete at first glance but is actually missing important information.
This guide identifies exactly which fields each major platform drops during VCF import, explains why each field is lost, and provides specific fixes to preserve every piece of contact data. If your VCF file failed to import entirely (as opposed to importing with missing data), see our VCF import error guide instead.
Why Fields Vanish During VCF Import
Contact data loss during import has four root causes, and understanding which one applies to your situation determines the right fix.
Unsupported property types. The VCF file contains properties that the target platform does not recognize. For example, Google Contacts does not import CATEGORIES (groups), and iCloud ignores X-SOCIALPROFILE from non-Apple sources. These properties exist in the file but the importer skips them entirely.
Format mismatch in property values. The field is supported but the value format does not match what the platform expects. Birthdays stored as BDAY:--1225 (month-day only, no year) import correctly on some platforms but are dropped on others that require the full BDAY:1990-12-25 format with a year.
Size limits on individual fields. The data exceeds the platform’s size limit for that specific field. iCloud rejects contact photos larger than 224 KB. Google Contacts truncates fields over 1,024 characters (except Notes). Oversized data is silently trimmed or discarded.
Encoding or version incompatibility. The property uses encoding or syntax from a different vCard version. A PHOTO property using a URL reference (common in vCard 4.0 and Google exports) will not be imported by platforms expecting inline Base64 photo data (required by vCard 3.0 and iCloud). The field is present but the platform cannot read the value format.
Which Fields Each Platform Drops
Contact Photos
Contact photos are the most commonly lost field during VCF import. There are three formats for storing photos in vCard files: inline Base64 data (the photo is embedded directly in the file), a URL reference (a link to the photo hosted online), and a file path reference. Each platform handles these differently.
Google Contacts exports photos as URL references (PHOTO:https://lh3.googleusercontent.com/...). When you import this VCF into iCloud or iPhone, the URL is ignored because Apple expects inline Base64 photo data. The contact imports but the photo is missing. Going the other direction, Apple exports photos as Base64 data, which Google Contacts can import, but large photos may exceed Google’s 20 MB total file limit.
iCloud has a strict 224 KB limit per contact photo. If the embedded photo exceeds this, iCloud drops the photo silently while importing the rest of the contact data. High-resolution photos from modern smartphones often exceed this limit after Base64 encoding (which increases data size by approximately 33%).
Birthdays and Anniversaries
The BDAY property supports multiple date formats across vCard versions. The full format BDAY:1990-12-25 works everywhere. However, some contacts only store month and day without a year, using formats like BDAY:--1225 (vCard 2.1/3.0) or BDAY:--12-25 (vCard 4.0). Google Contacts preserves year-less birthdays during import, but iCloud and Outlook require a year value and will drop birthdays in the month-day-only format.
Anniversary dates (stored as the X-ANNIVERSARY or ANNIVERSARY property depending on vCard version) are even more problematic. Google Contacts does not support anniversaries in VCF import. Apple Contacts imports them from Apple-generated vCards but may ignore them from other sources. Outlook supports anniversaries but uses a proprietary property format that other platforms do not recognize.
Postal Addresses
The ADR property uses a semicolon-delimited structure with seven components: PO Box, Extended Address, Street, City, Region, Postal Code, and Country. If the source application stored the address in a non-standard format (like putting the entire address in a single component), the importing platform may parse it incorrectly, resulting in all address data appearing in one field while the rest are empty.
Google Contacts exports addresses with a formatted label using item1.ADR and item1.X-ABLabel syntax (Apple’s grouped property format). While this is standard vCard, platforms like Outlook and Thunderbird sometimes fail to associate the label with the address, resulting in addresses that import but lose their Home, Work, or Other designation.
Notes
The NOTE property is generally well-supported across platforms, but long notes get truncated on some systems. Google Contacts has a 1,024-character limit per field (except Notes, which has a higher limit). Outlook has its own internal limits for note fields. If a CRM export packed conversation histories or detailed annotations into the NOTE field, the importing platform may truncate or discard the content.
Notes with line breaks can also cause issues. vCard 3.0 uses \n (backslash-n) to represent line breaks within a property value. If the importing application does not decode these escape sequences, the notes appear as a single long line with literal \n characters instead of actual line breaks.
Contact Groups and Labels
This is arguably the biggest silent data loss during VCF transfer. Google Contacts uses the CATEGORIES property to store group/label assignments. When you export from Google Contacts, the VCF file includes CATEGORIES:myContacts,Friends,Work for each contact. However, when you import this VCF into iCloud or iPhone, the CATEGORIES property is completely ignored. All contacts import into a flat list with no group assignments.
Apple stores groups through iCloud’s group management system rather than within individual vCard entries. Because group membership is stored separately from contact data, VCF export from Apple does not include group information either. Transferring contacts between Google and Apple using VCF files always loses group assignments in both directions.
Custom and X-Properties
Vendor-specific properties starting with X- are designed to be ignored by applications that do not understand them. Properties like X-SALESFORCE-ID, X-HUBSPOT-CONTACT-ID, X-SAMSUNG-ADDRESSBOOK, or X-MANAGER contain application-specific data that only the originating platform can use. When imported into a different platform, these properties are silently dropped because the receiving application has no way to map them to its own data model.
Social Profiles and URLs
Social media profiles are stored differently across platforms. Apple uses X-SOCIALPROFILE with subproperties for the service name and user ID. Google uses its own IMPP property or custom X-properties. Outlook uses entirely different property names. Because there is no universally standardized way to store social profiles in vCard, transferring this data between platforms almost always results in loss unless the source and target platforms happen to use the same property format.
Website URLs stored as the URL property generally survive import across platforms. However, contacts with multiple URLs may lose the type labels (Personal, Work, Blog) if the importing platform does not support URL type parameters.
Platform Compatibility Matrix
| Field | iCloud | iPhone | Outlook | Android | |
|---|---|---|---|---|---|
| Name, Phone, Email | Yes | Yes | Yes | Yes | Yes |
| Photo (Base64) | Yes | Under 224 KB | Under 224 KB | Yes | Yes |
| Photo (URL) | Yes | No | No | No | Varies |
| Birthday (with year) | Yes | Yes | Yes | Yes | Yes |
| Birthday (no year) | Yes | No | No | No | Varies |
| Anniversary | No | Apple only | Apple only | Yes | Varies |
| Address (structured) | Yes | Yes | Yes | Yes | Yes |
| Notes | Yes | Yes | Yes | Yes (truncated) | Yes |
| Groups / Categories | Yes | No | No | No | Varies |
| Social Profiles | Partial | Apple format only | Apple format only | No | Partial |
| Custom X-Properties | Stripped | Stripped | Stripped | Stripped | Stripped |
“Yes” means the field is imported and displayed. “No” means the field is silently dropped. “Varies” means behavior depends on the specific Android manufacturer and contact app version. “Partial” means some data is preserved but type labels or subproperties may be lost.
How to Check What Your VCF File Actually Contains
Before importing, verify which fields your VCF file contains so you know what to expect. Open the file in a text editor (Notepad, TextEdit, VS Code) and look for property lines. Each line starts with a property name followed by a colon and the value.
Search for these property names to check for specific fields: PHOTO (contact photos), BDAY (birthdays), ADR (addresses), NOTE (notes), CATEGORIES (groups), X-SOCIALPROFILE or IMPP (social profiles), ANNIVERSARY or X-ANNIVERSARY (anniversaries). If the property is present in the file but missing after import, the target platform dropped it.
You can also use a VCF viewer tool that displays all properties for each contact in a readable format, making it easier to see the full content before and after import without manually parsing raw vCard syntax.
How to Preserve All Fields During Import
Preserving Contact Photos
If photos are stored as URL references (common in Google exports), you need to download each photo and embed it as Base64 data in the VCF file before importing into iCloud or Outlook. A Python script using the requests library can automate this: fetch each photo URL, encode the image as Base64, and replace the URL reference with an inline PHOTO property. Resize photos to under 200 KB before encoding to stay within iCloud’s 224 KB limit (Base64 encoding increases the size by about 33%, so a 150 KB image becomes approximately 200 KB after encoding).
Preserving Birthdays
If birthdays are stored without a year and the target platform requires one, you have two options. The first is to add a placeholder year (like 1604, which many apps recognize as “year unknown”). Change BDAY:--12-25 to BDAY:1604-12-25. The second option is to use a converter tool that maps partial dates to the target platform’s expected format. After import, you can manually update contacts where the actual birth year is known.
Preserving Addresses
If addresses are losing their type labels (Home, Work) during import, check the property syntax in the VCF file. The standard format is ADR;TYPE=HOME:;;123 Main St;Springfield;IL;62701;US. If the type parameter uses a non-standard format like ADR;HOME: (missing the TYPE= prefix, common in vCard 2.1), update it to the 3.0 syntax with TYPE= prefixes. Similarly, if addresses use Apple’s grouped property format (item1.ADR with item1.X-ABLabel), platforms other than Apple may not parse the grouping correctly. Converting to standard ADR syntax with TYPE parameters ensures wider compatibility.
Universal Fix: Normalize Before Import
The most reliable approach for preserving maximum data is to normalize the VCF file for the specific target platform before importing. A VCF converter tool can remap properties between platform-specific formats: convert Google’s URL-based photos to inline Base64, convert Apple’s grouped properties to standard syntax, add placeholder years to partial birthdays, and strip or rename non-standard properties that the target platform would reject.
For the specific case of transferring contacts between Google and Apple (the most common scenario for missing fields), the Google-to-Apple workflow is: export from Google Contacts as vCard, run the file through a converter that downloads URL photos and converts them to Base64, then import into iCloud. The Apple-to-Google workflow is simpler because Apple’s vCard export is already well-structured, but you will still lose group assignments because neither platform preserves groups through VCF transfer.
Frequently Asked Questions
Why did my contact photos disappear after importing to iCloud?
iCloud has a 224 KB limit per contact photo. If the photo exceeds this after Base64 encoding, iCloud drops it silently. Also, if the VCF file stores photos as URL references (common in Google exports) instead of inline Base64 data, iCloud ignores them entirely. The fix is to download URL-referenced photos, resize them under 200 KB, and embed them as Base64 in the VCF before importing.
How do I transfer contact groups from Google to iPhone?
VCF files cannot reliably transfer groups between Google and Apple. Instead, export contacts from Google group by group, then create matching groups in iCloud manually and import each group’s VCF file into the corresponding iCloud group. This preserves the group structure even though the CATEGORIES property is lost during import.
My birthdays are missing after importing from Android to iPhone. Why?
Android phones often export birthdays without a year in BDAY:--MMDD format. iCloud requires a full date including year. Add a placeholder year (1604 is commonly used to indicate “year unknown”) to each birthday in the VCF file before importing to iCloud. After import, the birthday month and day will display correctly in iPhone Contacts.
Can I get back data that was already lost during import?
If you still have the original VCF file, yes. The data exists in the file even though the platform did not import it. Re-import the file after normalizing it for the target platform, or open the VCF file in a VCF viewer to see all fields and manually add the missing data to your contacts. If you deleted the original VCF file, the dropped fields cannot be recovered from the imported contacts.
Why does Outlook strip custom fields from my CRM contacts?
Custom X-properties from CRM systems (like X-SALESFORCE-ID or X-HUBSPOT-CONTACT-ID) are vendor-specific extensions that Outlook does not recognize. Since Outlook has no field to map this data to, it drops these properties during import. If you need to preserve CRM identifiers, export to CSV instead of VCF and map columns to Outlook’s custom fields during CSV import.
Is there any format that preserves all fields across all platforms?
No single format preserves everything across all platforms because each platform supports a different set of fields. vCard 3.0 with UTF-8 encoding has the widest compatibility for core fields (name, phone, email, address, birthday with year, notes, and inline photos). However, groups, social profiles, anniversaries, and custom properties will always require platform-specific handling. The closest to a universal approach is to maintain a master VCF file and create platform-specific exports for each target.
Conclusion
Last verified: February 2026. Field compatibility tested with Google Contacts (web), iCloud (web and Mac), iPhone (iOS 18), Outlook 365 (desktop and web), and Samsung Galaxy S24 (Android 15). VCF files tested across vCard 2.1, 3.0, and 4.0 from multiple source platforms.
Missing fields after VCF import happen because every platform silently drops properties it does not support. Photos stored as URLs are ignored by iCloud. Birthdays without years are dropped by Outlook and iPhone. Groups are lost when moving between Google and Apple. Custom X-properties are stripped by every platform. The key to preventing data loss is to check your VCF file contents before importing, understand what the target platform supports, and normalize the file format accordingly.
Three things to remember: photos need to be inline Base64 under 200 KB for maximum compatibility (not URLs, not oversized), birthdays need a full year (use 1604 as a placeholder if the year is unknown), and groups cannot be transferred via VCF between Google and Apple. Check the compatibility matrix in this guide before importing to set the right expectations and prevent surprises.
