Google Contacts CSV Import: Stop Phone and Address Fields Landing in Notes

9 min readPipeSheets Team

If your Google Contacts import finished without an error but every phone number, address, and email is crammed into the Notes field, the problem is your header row. Google reads the first row of the CSV to decide where each column goes, and it only recognizes an exact set of header names like Phone 1 - Value and Address 1 - Street. Any header it doesn't recognize gets dumped into Notes instead of being discarded. The fix is to export a Google CSV first, copy its exact header row into your file, and map your data underneath those headers before you re-import.

This is a different failure from the hard error where Google refuses the file and shows "The file you're importing isn't formatted for Google Contacts." That one blocks the import entirely. The problem here is a soft failure: the import succeeds, contacts get created, and everything looks fine until you open a contact and find the phone number sitting in the Notes box as plain text. No warning, no error, just data in the wrong place.

Why do my CSV fields end up in the Notes field?

Google Contacts does not ask you to map columns during import. There is no mapping screen, no dropdowns, no preview. It reads your header row and matches each column name against a fixed internal list of field names. When a header matches exactly, the values go to that structured field. When a header does not match, Google does not throw it away and it does not guess, it appends the column to the contact's Notes so you don't lose the data silently.

That behavior is why a spreadsheet exported from a CRM, a phone backup, or a hand-built contact list almost always lands in Notes. Your export calls the column Mobile, Cell, or Phone#. Google is looking for Phone 1 - Value. The names describe the same thing to a human, but the string doesn't match, so into Notes it goes. The matching is case-sensitive and space-sensitive, right down to the spaces around the hyphen.

The single most reliable fix is to never invent header names. Export a Google CSV from your own account first, then reuse that exact header row. Those are the canonical field names Google expects, copied straight from the source instead of typed from memory.

What header names does Google Contacts actually expect?

Google uses structured, numbered headers for anything that can repeat, one column for the type (Home, Work, Mobile) and a separate column for the value. A contact can have several phones and addresses, so the columns are numbered: Phone 1, Phone 2, and so on. The exact names for the fields people most often get wrong:

The header names Google matches on for the common fields:

Name parts: Given Name, Family Name, Additional Name, Name Prefix, Name Suffix
Phone: Phone 1 - Type and Phone 1 - Value (then Phone 2 - Type, Phone 2 - Value, and so on)
Email: E-mail 1 - Type and E-mail 1 - Value (note the hyphen in E-mail)
Address, split into components: Address 1 - Type, Address 1 - Street, Address 1 - City, Address 1 - Region, Address 1 - Postal Code, Address 1 - Country, and Address 1 - PO Box
Organization: Organization 1 - Name and Organization 1 - Title
Labels: the export field is named Group Membership; separate multiple labels with a space, three colons, and a space ( ::: )

The Type column is optional but useful: put Mobile, Home, or Work in Phone 1 - Type and Google files the number under that label. Leave the Type blank and the number still imports correctly as a phone, just without a label. What you cannot do is rename Phone 1 - Value to Mobile and expect Google to understand it. Mobile belongs in the Type column, never as the header of the value column.

Why "Mobile," "Cell," and "Phone#" headers fail

These are the headers almost every non-Google export produces, and every one of them lands in Notes. Mobile and Cell look like phone labels, but Google wants the label in Phone 1 - Type, not as the column header. Phone# has a stray character. Home Phone and Work Phone are close but still don't match the Phone 1 - Value pattern Google reads. The importer is matching a literal string, so close is the same as wrong.

Before: a typical export header row (all of this lands in Notes)
First Name,Last Name,Mobile,Email,Address
Maria,Gomez,555-0142,maria@example.com,"12 Oak St, Austin, TX 78701"

After: rebuilt with Google's exact header names
Given Name,Family Name,Phone 1 - Type,Phone 1 - Value,E-mail 1 - Type,E-mail 1 - Value,Address 1 - Street,Address 1 - City,Address 1 - Region,Address 1 - Postal Code
Maria,Gomez,Mobile,555-0142,Home,maria@example.com,12 Oak St,Austin,TX,78701

Notice two changes in the after version. First, every header now matches a name Google recognizes. Second, the address is no longer one blob. That single Address column is the other half of the problem, and it needs its own fix.

How to split one address column into Google's components

Google does not store an address as one string. It stores street, city, region, postal code, and country as separate fields. If your spreadsheet has a single Address column like "12 Oak St, Austin, TX 78701", there is no header that matches it, so the whole address drops into Notes. You have to break it into columns that line up with Address 1 - Street, Address 1 - City, Address 1 - Region, and Address 1 - Postal Code.

There is a shortcut header called Address 1 - Formatted that holds the full single-line address, and Google will accept it. But it treats the whole thing as one opaque block rather than parsing it into editable parts, so filtering by city or region later won't work well. For a clean, searchable contact list, split the address into its real components. The one edge case to watch: commas inside an address that isn't quoted will shift every following column by one, so keep multi-part values wrapped in double quotes until they're split apart.

Splitting a comma-jammed address by hand across hundreds of rows is where most people give up. A cleaning pass helps here: in PipeSheets you can load the file, use find and replace (including regex) to normalize separators, rename headers to the exact Google field names, and drop or reorder columns, then preview the before-and-after with detected column types before you export a clean CSV. That gets the header row and the address split right without fighting Excel, which likes to mangle leading zeros in postal codes and reformat anything that looks like a date.

Keep the header row intact, always

Google's own guidance is blunt about this: do not delete the header row. The header row is the only thing telling Google where each column belongs. If you delete it, the first real contact becomes the header and gets consumed, and every remaining row is interpreted against the wrong field names. Don't reorder the columns hoping to "line things up" either, order doesn't matter to Google as long as the names match, and reordering just invites mistakes. Match the names, leave the row in place, and let Google do the rest.

Rules for a header row that imports cleanly:

Keep the header as the very first row, never delete it
Match names exactly, including capitalization and the spaces around each hyphen (Phone 1 - Value, not Phone 1-Value or phone 1 - value)
Use E-mail, not Email, for the email value columns
Put labels like Mobile or Work in the Type column, never as the value column header
Don't add columns with invented names, any unrecognized header sends its whole column to Notes
Leave a cell blank rather than filling it with N/A or None, which imports as literal text

The reliable workflow: export first, then rebuild

Instead of typing header names from a guide and hoping the spacing is right, copy them from a real Google file. This takes five minutes and removes every guessing step.

Step by step:

In Google Contacts, create one dummy contact and fill in a phone, an email, and a full address so every field is populated
Export it: Google Contacts menu, Export, choose Google CSV
Open that export, this is your template with the exact, correctly spaced header row your account expects
Copy that header row into your own data file, then map your columns underneath it: names to Given Name and Family Name, phones to Phone 1 - Value, address parts to the Address 1 components
Clean and reshape the data (split the address, fix headers, clear placeholder nulls) before you import
Delete any Google columns you're not using, blank columns are fine and won't cause problems
Save as CSV with UTF-8 encoding so accented names don't turn into garbled characters

Validate with a 2-3 contact test import

Never import the full file first. Copy the header row plus two or three representative rows into a separate small CSV and import that. Then open one of those contacts and check the actual fields, not the preview. Is the phone number in the phone field or in Notes? Is the address split into street, city, and region, or sitting as one line? A three-contact test costs a minute and tells you immediately whether your header row is right.

If the test contact looks correct, everything in the field boxes and nothing unexpected in Notes, import the full file. If the phone number or address still shows up in Notes, one header is still off. Compare it character by character against your exported Google CSV: a missing space around the hyphen, Email instead of E-mail, or a trailing space is usually the culprit. Fix that one header and re-test before committing the whole list.

If a test import created bad contacts, undo it before re-importing. Google Contacts keeps an "Undo changes" option under Settings that reverts your contacts to an earlier point in time, so you don't end up with duplicates from repeated test runs.

Fixing the file once, cleanly

The whole problem reduces to two edits: rename your headers to Google's exact field names, and split any combined columns (especially the address) into the components Google stores separately. Do both, keep the header row in place, and run a small test import to confirm. When the source export is messy, drop the file into PipeSheets first to rename headers, split and normalize columns, clear placeholder nulls, and preview the result, so the version you hand to Google already has the header row it's looking for. Match the names Google expects and your phone numbers and addresses land exactly where they belong.