How to Import Contacts into HubSpot: 2026 Guide

Before you import: prepare the file

HubSpot accepts .csv, .xlsx and .xls files. A clean import starts in the spreadsheet, not in HubSpot. Spend ten minutes here and you save hours of cleanup later.

One header row. The first row should hold your column names and nothing else. Remove merged cells, title rows, totals and blank spacer columns.

One value per cell. Split combined fields. "Jane Smith" should be a First Name column and a Last Name column. A single "Address" blob should become street, city, postcode and country columns if you want them as separate properties.

A unique identifier. Email address is the default. If you are updating existing records rather than creating new ones, make sure the column you will match on (email, or a Record ID exported from HubSpot) is present and accurate.

Consistent formatting. Standardise phone numbers, dates and country names. HubSpot will not silently fix "UK", "U.K." and "United Kingdom" for you, and inconsistent values fragment your reporting and segmentation downstream.

Deduplicate the file first. Sort by email and remove duplicate rows before you upload. HubSpot deduplicates against records already in the CRM, but it does not clean duplicates inside the file you give it.

The import steps in the current HubSpot UI

The flow below reflects HubSpot's current navigation. The labels shift slightly between updates, but the sequence is stable.

From the main navigation, go to CRM > Contacts.

Click Import in the top right, then Start an import.

Choose File from computer and click Next.

Select One file, then One object, and choose Contacts as the object type. (If your file also contains company, deal or other object data, choose "Multiple objects" so HubSpot can associate the records as it imports.)

Upload your file by drag-and-drop or by browsing to it.

Map your columns to HubSpot properties. This is the step that matters. HubSpot auto-matches obvious columns, but check every row. Unmapped columns are skipped, and a column mapped to the wrong property quietly corrupts your data.

Decide whether to create new records, update existing ones, or both, and confirm the property HubSpot will use to match against existing contacts.

Name the import (use something you will recognise later, such as "2026-Q1 webinar list") and review the summary.

Click Finish import. HubSpot processes the file and shows you how many records were created, updated and skipped, with an error log you can download.

Field mapping: where imports go wrong

The mapping screen is where most imports come unstuck. A few rules keep it clean:

Create custom properties before you import, not during. If you need a "Lead Source Detail" or "Account Tier" field, build it in your contact property settings first, set the correct field type (dropdown, number, date), and then map to it. Creating properties on the fly during an import is how teams end up with three slightly different versions of the same field.

Match field types. A date column must map to a date property, not a single-line text field. A dropdown property only accepts values that already exist as options. Mismatches show up as skipped values in the error log.

Do not map columns you do not need. Every column you import is a property someone has to maintain. Leave noise out.

Use the error log. After the import, download the file of skipped rows, fix the values, and re-import only those. Never re-upload the whole file to chase a handful of errors, because you risk creating duplicates.

Deduplication and property hygiene

HubSpot automatically deduplicates contacts by email address and by an internal Record ID. That protects you against the most common case, but it does not catch everything. Two records for the same person under a personal and a work email will both survive. So will a company entered as "Acme Ltd" once and "Acme Limited" another time.

For a one-off list of a few hundred contacts, manual review is fine. For mid-market teams importing tens of thousands of rows, or pulling lists in from events, an old CRM, a finance system or a spreadsheet that several people maintain, ad hoc imports are how a database degrades. Each import adds a little inconsistency, and over time segmentation, reporting and any AI or automation built on top of that data become unreliable. The fix is to treat contact data as something you engineer and govern, not something you paste in. That means agreed naming conventions, a small set of well-defined properties, and validation at the point of entry rather than cleanup after the fact.

When a manual import is not the right tool

The import wizard is built for occasional, finite lists. If you find yourself running the same upload every week, syncing the same source repeatedly, or migrating an entire CRM, you have outgrown it. At that point a managed sync or a proper migration is faster, safer and far less error-prone than a recurring manual upload.

Recurring or live data from another system is better handled by a connected integration than by repeated manual files. See how we approach this on HubSpot integrations, and browse ready-made connectors in the integration library.

Moving everything from another CRM involves history, associations and custom objects that a contact import cannot carry. That is a data migration, not an import.

Ongoing data quality across imports, integrations and teams is a data engineering problem, and solving it once keeps every future import clean.

Get the file right, check every mapped field, and use the error log, and a manual import will serve you well for one-off lists. When the volume, frequency or complexity grows beyond that, the answer is to build the pipeline rather than repeat the upload.