Why your HubSpot import is failing

HubSpot does not fail an import as one lump. It imports the rows it can and lists the rows it could not, with a reason against each. That list is the useful part, and it is easy to miss.

Open the import from the imports list and download the error file. It gives you the failing rows with the error name attached, which turns a vague failure into a specific fix. Everything below is keyed to those error names.

Worth knowing before you go back to the spreadsheet: some of it can be fixed inside the import tool. At the mapping stage you can replace a value and HubSpot applies the change to every row in that column where it appears, which handles a misspelling repeated across hundreds of rows. That works well for one or two bad values. It stops being the quicker route when several columns need work, or when the same file arrives every month.

Find the message from your error file below, then go to the section that fixes it. The error names are HubSpot's own, as its Review and troubleshoot record import errors article lists them (updated September 25, 2026). The table covers the errors this page fixes; that article lists every one and says what it means, and this page says how to fix the file.

Most of these stop the import before a single row is read; Row data too large skips only the row that is too big. They are the quickest to fix and the most common cause of a file that will simply not upload.

These are about the header row and the properties behind it. HubSpot has to turn each of your column names into one of its own properties, and it will tell you when it cannot.

These are the ones that let most of the import through and quietly drop the rest, which is why an import can look successful and still leave you short.

HubSpot matches on a unique identifier, usually email for contacts and domain for companies. Most of these errors mean your file disagrees with itself about which record is which.

You can bring contacts and their companies in with one file or two. In one file, each row holds a contact and its company, with an identifier for each: Email or Record ID for the contact, Company domain name or Record ID for the company. Leave the identifiers out and HubSpot creates duplicate records instead of linking each contact to its company.

A contact who belongs to two companies takes two rows, with the same email and a different company domain in each. With two files, one for contacts and one for companies, both need a column in common that connects the records. If both files carry Record IDs, name the columns apart, for example Record ID - Contacts and Record ID - Companies.

Company domain name keeps only the domain: anything after it, such as /about, is removed on import. When one domain matches several companies already in HubSpot, HubSpot leaves that company unchanged and lists Multiple companies with this domain. Merge or delete the extra companies, or import with Record ID instead.

This is not really an error, and it catches people out more than the errors do. HubSpot asks whether the import should create records, update them, or both, and it does exactly what you chose.

Create only import means your file matched existing records and HubSpot left them alone, as instructed. Update only import means the opposite: rows that matched nothing were skipped rather than created. If you meant to do both, choose create and update, and run it again.

Some errors are about your HubSpot account rather than your spreadsheet, and no amount of cleaning will move them.

Limit exceeded means you have hit your record allowance. GDPR blocklisted email means those contacts cannot be added by import at all, whatever the file says. Those two are HubSpot-side decisions, and the file is not the lever. Association errors are mostly about the file, and they are under Importing companies and contacts together.

Every error above announces itself. The imports that cause real trouble are the ones that succeed. Nothing is rejected, the summary looks healthy, and the damage only surfaces days later when a report is wrong or a rep asks why a contact went cold.

Experienced HubSpot admins consistently name the same handful. An import can overwrite Original Source, which is the field your attribution reporting rests on. It can move Lifecycle Stage, sometimes backwards. It can replace tidy dropdown values with free text typed by whoever built the file. It can break company associations, change record owners and the routing that depends on them, and land values in the wrong property entirely because two columns had similar names. See CRM imports.

The one that surprises people most: an import can trigger workflows. If enrollment criteria match the records you just touched, automation fires on all of them at once, and that can mean live emails going out to a few thousand people who were not expecting them.

An Apollo people export usually imports into HubSpot with few errors. The trouble is in what it brings with it: more than 70 columns, some named so that HubSpot maps them to the wrong property. These are the ones to deal with before you upload.

None of this is difficult. It is the difference between an import you can undo and one you cannot.

Most of the list above comes from three things: a header row that does not match, values that do not match a dropdown, and duplicates. HubSpot lets you patch some of these in the import tool one value at a time, which is fine once. It is the wrong shape when the same export arrives every month, because you are redoing the same corrections by hand each time.

Clean Headers standardizes the header row and removes the blank and duplicate names behind Incorrect number of columns and Property definition not found. Find & Replace collapses the spelling variants behind Invalid enumeration option. Deduplicate removes the repeated identifiers behind Duplicate unique property value. Excel to CSV takes one sheet out of a multi-sheet workbook, which is Invalid sheet count. The CRM Formatter maps your columns onto HubSpot's real property names and shows a preview of what will be created and updated before anything is written.

Dates have two fixes and it is worth knowing both. HubSpot asks you to pick a date format during the import, so choosing the one your file already uses often solves it without touching a cell. When the column itself is inconsistent, which is the harder case, Data Health Check flags the mixed formats and its Standardize dates fix converts them to YYYY-MM-DD, reading the column in its own day and month order. A date that could be either, in a column that doesn't settle it, is left as it is for you to check.