How to Normalize Country Names in HubSpot

Pull up any HubSpot portal that has been in use for more than a year and filter by the country property. In a perfect world, you would see a clean list: United States, Canada, United Kingdom, Germany. In reality, you will see something like this:

• US
• USA
• U.S.
• U.S.A.
• United States
• United States of America
• united states
• Unites States (yes, the typo)
• Amerika

And that's just one country. Multiply the variations across every country your contacts come from, and you're looking at a property that is functionally useless for segmentation, reporting, or automation.

Here is what normalizing those variants down to a single standard value looks like:

Where the mess comes from

Country data enters HubSpot through at least five channels, and none of them agree on formatting.

Manual entry. When the country field is a free-text input, every rep types it differently. Some use abbreviations, some use full names, some use whatever autocomplete suggests on their phone.

Form submissions. If your HubSpot forms use a text field for country instead of a dropdown, you get whatever the visitor types. Even with a dropdown, some forms use ISO codes (US, GB), while others use full names.

CSV imports. Every data source formats countries differently. Salesforce exports might use "United States," a purchased list might use "USA," and your marketing team's spreadsheet might use two-letter ISO codes.

Integrations. Zapier, PieSync, third-party tools — each passes through whatever format the source system uses. A Stripe integration might send "US" while an Intercom integration sends "United States."

HubSpot's own IP-based detection. When HubSpot auto-populates the country field from a visitor's IP address, it uses its own format, which may differ from what's already in the record.

Why it matters more than you think

Country is one of the most commonly used properties in HubSpot for segmentation and automation. When it's inconsistent, the downstream impact is significant.

Smart lists break. If you build a list where "Country is equal to United States," you miss every contact stored as "US," "USA," or "U.S." That list is undercounting, and any campaign sent to it has incomplete reach.

Workflows branch incorrectly. A workflow that routes leads to regional sales teams based on country will misroute anyone whose country value doesn't match the exact string in your branch logic. Your EMEA team gets US leads, your US team never sees contacts stored as "Amerika."

Reports are misleading. A report showing deals by country will display "US" and "United States" as separate bars. Your board deck now shows the US market split into five fragments, and nobody trusts the numbers.

Personalization fails. Email tokens that pull the country property will display whatever is stored. A polished outreach email that says "We work with many companies in USA" reads worse than one that says "United States."

Picking your standard

You have three reasonable options:

Full English names (United States, United Kingdom, Germany). These read well in personalization tokens, reports, and the HubSpot UI. This is what most B2B companies choose.

ISO 3166-1 alpha-2 codes (US, GB, DE). These are compact, unambiguous, and machine-friendly. Good if your data flows between multiple systems and you want a universal key. Less readable in emails and reports.

HubSpot's internal dropdown values. If you use HubSpot's built-in Country dropdown property (not a free-text field), HubSpot has a predefined list of country names. Matching these exactly ensures compatibility with HubSpot's own filtering and reporting.

For most teams, full English names are the best balance of human readability and CRM usability. Whatever you choose, document it and communicate it to everyone who touches the data.

The manual cleanup path

If you have a small portal (under 500 contacts), you can do this manually:

1. Export contacts to CSV
2. Create a lookup column mapping every variation to the standard name
3. Use VLOOKUP or a similar formula to populate a corrected column
4. Re-import the CSV, mapping the corrected column to the country property

This works, but it's tedious and error-prone. You have to know every variation in advance (you'll miss some), the import overwrites without preview, and there's no undo if something goes wrong. For portals with thousands of records or ongoing data quality issues, you need a repeatable process.

Systematic cleanup with SearchReplace

The most efficient approach is to work through country variations one by one, starting with the highest-frequency mismatches.

Start with a recon pass. Search the country property across your contacts for common abbreviations. A search for ^US$ (exact match, regex) reveals how many contacts use the two-letter code. A search for ^USA$ shows the three-letter version. A search for U\.S catches U.S. and U.S.A.

Build your replacement list. For the United States alone, you typically need these operations:

Each operation gets a full preview — you see every affected record and the proposed new value before anything changes. Apply them one at a time, verify, move on.

Handle the United Kingdom next. Common variants: UK, U.K., Great Britain, England (technically not the same, but often used interchangeably in CRM data), GB.

Then work through your other high-volume countries. Germany / Deutschland / DE. Canada / CA / CAN. Australia / AU / AUS. France / FR. The long tail will have fewer records and fewer variants.

Catch typos last. Search for near-matches: Untied States, Uited Kingdom, Canad. These won't match a simple pattern, but a substring search for Untied or Uited will surface them.

Dealing with companies, deals, and tickets

Country data doesn't live only on contacts. Companies have billing and shipping addresses with country fields. Deals inherit company data. Tickets might have a country field for support routing.

Run the same normalization across all object types. The variations will be different — company records often come from enrichment tools that use their own formatting, while ticket data might come from a support form with different options.

Preventing recurrence

Once you've cleaned up, close the entry points.

Switch to dropdown fields. If your country property is a free-text field, convert it to a dropdown with a predefined list. HubSpot's default Country/Region property is already a dropdown — use it instead of a custom text field if possible.

Standardize on forms. Every HubSpot form that collects country data should use a dropdown, not a text input. If you use external forms that submit to HubSpot, ensure they map to the dropdown values.

Clean on import. Before every CSV import, run the country column through a standardization pass. A simple spreadsheet formula using SUBSTITUTE or SWITCH can handle the most common variations. Better yet, create a template with the approved values and use data validation.

Audit integrations. Check what format each integration sends. If Salesforce sends "US" and you want "United States," add a transformation in your integration tool (most iPaaS platforms support this) or run a periodic cleanup.

Set up a monitoring workflow. Create a HubSpot workflow that triggers when the country property is updated to a value not in your approved list. The workflow can set a flag property or notify an ops team member to investigate. This won't fix the data automatically, but it catches drift before it compounds.

A note on non-English country names

If your contacts or team members span multiple languages, you may encounter country names in their native language — Deutschland for Germany, Espana for Spain, Brasil for Brazil. Decide upfront whether you standardize to English names or native names, and be consistent. Most international B2B companies standardize to English since it's the common language in HubSpot's interface and reporting.

Country normalization is not glamorous work. But it is foundational. Every segmentation, every automation branch, every report that filters by geography depends on this field being consistent. An afternoon spent cleaning it up will improve the accuracy of everything built on top of it.