How to Fix Special Characters in HubSpot Data

You open a contact record in HubSpot and see a company name like Café Express or a note that reads We’re excited to announce.... The accented characters, curly quotes, and special symbols that were perfectly legible in the source system have turned into garbage. Programmers call this "mojibake" — a Japanese term that loosely translates to "character transformation" — and it happens when text encoded in one character set is interpreted as another.

If this is showing up in your HubSpot data, you have an encoding problem. The good news: it's fixable. The bad news: you need to understand a little about why it happens to fix it correctly.

Why characters break

Every piece of text on a computer is stored as a sequence of numbers. A character encoding maps those numbers to visual characters. The two encodings you'll encounter most often are:

UTF-8: The modern standard. It can represent every character in every language, plus emojis, mathematical symbols, and more. HubSpot uses UTF-8 internally.

Latin-1 (ISO 8859-1) or Windows-1252: Older encodings that cover Western European languages but not much else. They use one byte per character, which means they can only represent 256 different characters.

The problem occurs when text encoded in UTF-8 is read as if it were Latin-1, or vice versa. A UTF-8 encoded é (which uses two bytes: 0xC3 0xA9) gets read as two Latin-1 characters: Ã (0xC3) and © (0xA9). Hence Café becomes Café.

This almost always happens during CSV imports, data migrations, or integration syncs where the encoding isn't specified or is incorrectly specified.

Common mojibake patterns

The damage follows predictable patterns. Here are the most frequent broken character sequences and what they should be:

The curly quote problem

The most common encoding casualty in business data is the curly (or "smart") quote. Microsoft Word, Outlook, Apple Mail, and Google Docs all convert straight quotes (' and ") to curly quotes (' ' " ") automatically. These curly quotes are multi-byte characters in UTF-8.

When a Word document or email gets pasted into a spreadsheet and exported as a CSV with the wrong encoding, every apostrophe and quotation mark breaks. You end up with:

• We’re instead of We're
• “Great product!â€ instead of "Great product!"
• can’t instead of can't

This is cosmetically terrible and practically damaging. It shows up in email personalization, on invoices, in report exports, and anywhere else HubSpot displays the text.

Fixing encoding issues

Option 1: Fix the source and re-import

If the broken data came from a recent import and you still have the source file, the cleanest fix is to re-export from the source with the correct encoding and re-import into HubSpot.

When exporting a CSV, ensure the file is saved as UTF-8 with BOM (Byte Order Mark). The BOM tells the receiving application that the file is UTF-8. In Excel: Save As > CSV UTF-8. In Google Sheets: Download as CSV (always UTF-8 by default).

When importing into HubSpot, HubSpot expects UTF-8. If your file is correctly encoded, special characters will come through intact.

Option 2: Fix the data in place

If re-importing isn't practical — the source file is gone, the data has been modified since import, or the broken characters entered through an integration — you need to fix the data where it lives.

The approach is a series of targeted find-and-replace operations, one for each broken character pattern.

Start with the highest-frequency patterns. In most English-language portals, the curly quote replacements fix the majority of visible problems:

1. Search for ’ and replace with ' (apostrophe)
2. Search for “ and replace with " (opening double quote — or use a straight quote if you prefer)
3. Search for â€ and replace with " (closing double quote)
4. Search for â€" and replace with — (em dash)

Then fix accented characters if your data includes names or words from Romance languages:

5. Search for é and replace with é
6. Search for è and replace with è
7. Search for ñ and replace with ñ
8. Search for ü and replace with ü
9. Search for ö and replace with ö

Clean up stray  characters. The Â character (followed by a space or special character) is a telltale sign of double-encoding. Search for  ( followed by a space) and replace with a space. Search for © and replace with ©. Search for ® and replace with ®.

Option 3: Regex for broader patterns

If you have widespread encoding damage, you can use broader regex patterns to catch multiple issues at once. For example, Ã. matches Ã followed by any character, which catches most accented-character mojibake. But preview this carefully — you don't want to replace a legitimate Ã followed by a normal character.

Working through it in SearchReplace

Here's what cleaning up HTML artifacts from contact notes looks like — the same approach works for broken character sequences:

Each broken character pattern becomes a single search-and-replace operation. Select the affected property (or all properties if the damage is widespread), enter the broken sequence as the search string, enter the correct character as the replacement, and preview.

The preview is essential here. Encoding issues can be subtle:

• The broken sequence ’ might appear in the middle of legitimate text that you want to keep
• Some records might have the correct character already, and you want to confirm you're not touching those
• Double-encoded text (encoded incorrectly twice) needs two rounds of fixing

For a typical portal with encoding issues from a single bad import, you'll run 8-15 replacements covering the common patterns. Each one takes a minute or two with preview verification. The entire cleanup can be done within an hour.

Double encoding: when it gets worse

Sometimes data gets encoded incorrectly twice. This happens when a system that already mangled the encoding exports the mangled text and the receiving system mangles it again.

The result is even more garbled: é (the mojibake for é) gets encoded again to é. At this point, the text is nearly unreadable: Café Express.

Fixing double encoding requires two passes:

1. First pass: fix the outer layer of encoding (é back to é)
2. Second pass: fix the inner layer (é back to é)

If you try to do it in one step, you'll likely miss patterns or create new problems. Work through it methodically.

Properties most likely to be affected

Not every property in your HubSpot portal will have encoding issues. Focus your search on:

• Contact and company names — especially names with accented characters (common in French, Spanish, German, Portuguese names)
• Notes and descriptions — long text fields that were likely authored in Word or Outlook
• Addresses — city and street names with special characters (São Paulo, Zürich, Malmö)
• Custom text properties — anything imported from an external source
• Deal names — often copied from emails or proposals

Single-value properties like email addresses and phone numbers are less likely to have encoding issues because they use only ASCII characters.

Preventing encoding problems

Always use UTF-8 for CSV files. This is the single most effective prevention measure. When exporting data for import into HubSpot, save as UTF-8. When in doubt, open the CSV in a text editor (not Excel — Excel mangles encoding) and verify the special characters display correctly.

Test imports with a small batch first. Before importing 10,000 contacts, import 10 that include accented characters. Check the records in HubSpot to verify the characters survived the import intact.

Check integration documentation. When setting up a new integration, look for encoding settings. Some integrations let you specify character encoding for data transfer. Set it to UTF-8 explicitly.

Avoid copy-paste from Word. If reps paste text from Microsoft Word into HubSpot, the curly quotes and special characters will usually survive because the browser handles the encoding correctly. But if they paste into a spreadsheet first and then import, the encoding chain is broken. Train your team to paste directly into HubSpot or to use straight quotes.

Watch for Excel's encoding traps. Microsoft Excel is notorious for re-encoding CSV files when you open and save them. If you open a UTF-8 CSV in Excel, make edits, and save it, Excel may silently convert it to Windows-1252 encoding. Use "Save As" and explicitly choose "CSV UTF-8" to prevent this.

Encoding issues are frustrating because they look like random garbage, but they follow deterministic patterns. Once you know which sequences map to which characters, fixing them is mechanical. The key is catching them early — before they propagate into emails, reports, and customer-facing communications.