Skip to content
Runner Blog
Esc
↑↓navigate↵open⌘Jpreview
On this page
Product Data10 min read

UTF-8 Encoding for CSV Files: Keep Product Data Readable

A practical guide to creating, checking, and troubleshooting UTF-8 CSV files before importing product data into an ecommerce catalog.

By Runner AI Team

A product catalog spreadsheet passing through an encoding check before entering an online store

UTF-8 encoding CSV preparation preserves the intended characters when tabular text moves between spreadsheets, databases, and import tools. It helps product names such as “Café Mug” and text in non-Latin scripts survive the handoff. It does not prove that columns, quotes, prices, or variants are correct. Runner users should check both character encoding and the product-import contract before changing a catalog.

Key takeaways

  • CSV describes the table; UTF-8 describes how its characters are stored as bytes.
  • A UTF-8 byte order mark can help Excel recognize a file, but UTF-8 does not universally require one.
  • Reopen the exported file and inspect representative names, symbols, delimiters, headers, and row counts.
  • Conversion cannot reliably recover a character that an earlier step already replaced with ? or �.
  • In Runner, use the current product template, start the import once, follow History, and inspect the resulting products.

CSV format and UTF-8 encoding solve different problems

The most important distinction is simple: CSV controls structure, while UTF-8 controls character representation. A file can pass one test and fail the other.

CSV is a text format for rows and fields. Commas usually separate fields, line breaks separate records, and quotes protect a field that contains a comma, quote, or line break. UTF-8 is a Unicode encoding form that turns characters into byte sequences. The Unicode Standard’s conformance rules require a process interpreting UTF-8 to treat ill-formed byte sequences as errors rather than reinterpret them as characters.

The text/csv media type reflects this separation. RFC 7111, published in January 2014, defines charset as an optional parameter and says UTF-8 should be assumed when it is absent. That registration describes data exchanged as text/csv; it does not guarantee that every spreadsheet or legacy importer will make the same guess when opening a local file.

Consider three independent failures:

File state What can still go wrong
Valid CSV, wrong character encoding Crème brûlée may reopen as garbled text even though every row and comma is in place.
Valid UTF-8, broken CSV syntax An unquoted comma in a description can shift every later value into the wrong column.
Valid UTF-8 and valid CSV syntax, wrong import contract A destination can reject unknown headers or create the wrong variants from otherwise readable data.

This is why “save as UTF-8” is necessary advice for many imports, but never the whole checklist.

What is the difference between CSV and CSV UTF-8?

“CSV UTF-8” usually means a comma-delimited text file whose characters are encoded as UTF-8. It is not a richer spreadsheet format. Formulas, multiple sheets, styling, filters, and cell types are generally not preserved as spreadsheet features when a workbook is exported to CSV.

The label matters because older CSV workflows often used a local legacy encoding. Those encodings may represent only a limited set of characters or assign different meanings to the same byte values. UTF-8 can represent the characters in the Unicode repertoire, including accented Latin letters, Greek, Arabic, Chinese, Japanese, and many symbols used in international catalogs.

Encoding still cannot correct the underlying product facts. A properly encoded row can contain the wrong SKU, a price in the wrong currency, an image for another variant, or a duplicate product handle. The broader ecommerce product data guide explains how field ownership and validation protect those facts after the characters themselves are readable.

UTF-8 with BOM versus UTF-8 without BOM

A byte order mark, or BOM, is a short signature at the beginning of a text stream. UTF-8 is byte-oriented and does not need the marker to establish byte order. Some software still uses it as a signal that the file is UTF-8.

This creates a practical compatibility choice:

  • UTF-8 with BOM can make recognition easier in some desktop spreadsheet workflows.
  • UTF-8 without BOM is valid UTF-8 and is common in web and data systems.
  • The destination’s documented behavior wins. Do not add or remove a BOM solely because another tool prefers the opposite form.

Microsoft’s guidance says Excel can normally open a UTF-8 CSV saved with a BOM. For a UTF-8 file without one, Microsoft recommends importing through Data → Get Data → From Text/CSV or using the Text Import Wizard. That is Excel-specific guidance, not a rule that every UTF-8 CSV needs a BOM.

Runner’s product-import workflow does not ask users to choose a BOM option. Start from Runner’s current template and use an explicit UTF-8 CSV export when your editor offers it. If a separate source or destination publishes an encoding requirement, follow that requirement for that handoff.

Signs that a CSV has an encoding problem

An encoding problem usually appears as changed characters, not shifted columns. Look for these symptoms after export or import:

  • Accented names show ?, �, or sequences such as é.
  • A non-English product name becomes blank or unreadable.
  • Currency and measurement symbols change.
  • Text looks right in the original workbook but wrong after the CSV is reopened.
  • One application displays the file correctly while another does not.

These symptoms differ from structural CSV problems. If a description breaks into several columns, inspect delimiters and quoting first. If every value remains under the right header but some letters are damaged, inspect encoding. If the file is readable and aligned but the destination rejects it, compare its headers and field rules with the destination template.

Visible inspection is useful but not complete proof. A file can look fine if the sample contains only basic English letters and digits. Include representative values in your check: an accented product title, a non-Latin name if your catalog uses one, a currency symbol, and a description containing punctuation.

How to create and verify a UTF-8 encoded CSV file

The safest route is to export again from the clean source rather than convert a damaged intermediate file.

  1. Keep an untouched source copy. Preserve the original workbook or export so a failed conversion does not become the new master.
  2. Use the destination’s template. Put your data into its current headers instead of renaming columns after export.
  3. Choose an explicit UTF-8 CSV option. In applications that list several CSV formats, select the one labeled CSV UTF-8 or choose UTF-8 in the text-encoding control.
  4. Confirm the delimiter. A regional spreadsheet setting may export semicolons while the destination expects commas.
  5. Save to a new file. This leaves the original available for comparison.
  6. Reopen the actual CSV. Do not rely on how the source workbook looked before export.

If you use Apple Numbers to inspect a delimited text file, Apple documents a Text Encoding control in Adjust Import Settings. LibreOffice likewise exposes import and export settings for opening and saving Text CSV files. Menus vary by version, so verify the selected encoding and delimiter in the preview rather than following screenshots blindly.

Online converters can be convenient, but they introduce two questions. First, automatic encoding detection is an inference, not a guarantee; several legacy encodings can be ambiguous from a small sample. Second, a product CSV may contain unpublished prices, identifiers, supplier details, or other business data. Prefer a trusted local export path, or verify that a converter processes files locally before giving it sensitive catalog data.

How to verify UTF-8 before an import

Verification should preserve the file and test the values most likely to reveal damage.

  1. Open the exported CSV through your spreadsheet’s text-import flow and explicitly select UTF-8 when available.
  2. Confirm accented letters, non-Latin scripts, symbols, and punctuation against the source.
  3. Check that the header row is unchanged.
  4. Inspect a description containing a comma or line break to confirm that quoting preserved one field.
  5. Compare the source and CSV row counts, allowing only deliberate header or blank-row differences.
  6. Check identifiers as text so an editor has not removed leading zeroes or converted long values to scientific notation.
  7. Save no further changes unless the application will preserve the selected encoding and CSV structure.

If the CSV already contains ? or � where a real character should be, return to the last source that still displays the intended text. Changing the damaged file’s label to UTF-8 only encodes the replacement character correctly; it does not reveal which original character was lost.

UTF-8 is only the first product-import gate

A reliable product import uses several gates in order. Each gate answers a different question and points to a different fix.

Gate Question Typical fix
Character encoding Can the intended text be decoded without loss? Export again as UTF-8 from a clean source.
CSV structure Are delimiters, quotes, headers, and row widths consistent? Correct the export settings or malformed fields.
Import contract Do the headers and accepted fields match the destination’s current template? Move data into a fresh destination template.
Product data Are titles, handles, variants, prices, and SKUs accurate? Correct the authoritative product record.
Import outcome Did the destination create the records you expected? Inspect the result before repeating or expanding the import.

A separate Runner workflow, not the Import Products dialog, strictly rejects malformed UTF-8. That workflow accepts a leading UTF-8 signature and reports encoding failures separately from invalid CSV syntax, missing headers, inconsistent columns, and unsafe cells. The ordinary product-import dialog follows a different path: it checks for a .csv file, reads non-empty text, and waits for the user to select Start Import. A “Ready to import” file selection is therefore not a promise that every product fact is correct.

That distinction keeps the advice honest: encoding checks protect text, while import review protects the catalog.

Prepare a product CSV for Runner AI

Runner’s documented workflow is designed around a current template and an explicit catalog-changing action. Use it this way:

  1. In a ready store, open a populated product list on desktop, then select Import. An empty catalog shows Add First Product, and the mobile view emphasizes manual creation.
  2. Select Template to download Runner’s current product-import-template.csv.
  3. Keep the template headers. The documented workflow requires Product Handle and Product Title; use the option fields shown by the template for variants, and add Variant SKU when your catalog uses SKUs.
  4. Copy product data from the authoritative source, then review handles, titles, prices, variants, and repeated rows. If prices are still being decided, complete the product pricing method before treating the CSV as final.
  5. Export the completed sheet as a UTF-8 CSV where your editor provides that choice.
  6. Reopen the exported file and run the encoding and structure checks above.
  7. Upload the file. Selecting it prepares the data; only Start Import submits the catalog change.
  8. Follow the task in History. Do not submit a duplicate merely because it is Pending or Processing.
  9. After a terminal state, refresh Products and inspect names, variants, prices, status, and inventory.

The Runner product-import guide documents the current controls, prerequisites, and History states. Test a small representative product set before moving the full catalog, then compare the resulting products with the reviewed source file.

Troubleshoot the layer that failed

Treat the symptom as evidence about which gate to inspect. Repeatedly re-uploading the same file makes duplicate or partial outcomes harder to reason about.

Symptom Likely layer Next check
Accents or scripts are garbled Encoding Return to the clean source and export explicitly as UTF-8.
Excel opens UTF-8 text incorrectly Application decoding Use Get Data → From Text/CSV and select the encoding, or use a compatible BOM export.
Data shifts into later columns CSV structure Check the delimiter and quote fields containing commas, quotes, or line breaks.
Import rejects or misreads headers Import contract Download a fresh template and restore its exact headers.
Import finishes but products are wrong Product data or mapping Compare handles, variants, prices, and SKUs with the submitted file.
History remains Pending or Processing Task state Refresh History later instead of starting the same import again.

If you need a broader review of product identifiers, source ownership, channel handoffs, and publication checks, use the product data audit workflow. If your goal is to evaluate how Runner supports reviewable catalog work after data preparation, see AI ecommerce catalog management.

Frequently asked questions

Is a CSV file always UTF-8?

No. CSV describes a text table, but the characters can be stored with different encodings. RFC 7111 says UTF-8 should be assumed for text/csv when a charset is absent, yet local files and older applications do not always follow that behavior. Choose UTF-8 explicitly when preparing an import.

Does UTF-8 require a BOM?

No. UTF-8 does not need a byte order mark to establish byte order. A BOM can act as an encoding signature and can help some versions of Excel recognize UTF-8, while other consumers may not expect it. Follow the destination’s guidance.

Can converting to UTF-8 repair broken characters?

Only if the converter correctly identifies the original bytes and those bytes still contain the intended information. Automatic detection can be ambiguous, and a mislabeled conversion can produce different damage. If an earlier step replaced a character with ? or �, later conversion usually cannot determine what the original character was. Re-export from the last clean source instead.

Does valid UTF-8 mean a CSV is ready to import?

No. Valid UTF-8 says the byte sequences can represent Unicode text. It does not test how that text is organized or whether its claims are accurate. The CSV may still have malformed quoting, inconsistent columns, wrong headers, duplicate handles, inaccurate prices, or incorrect variants. Validate the destination contract and product records separately.

What is the safest way to import product data into Runner?

Download Runner’s current template, preserve its headers, prepare and review the product rows, export as UTF-8 CSV, and reopen the actual file to check characters and structure. Starting an import changes the catalog, so submit it once and follow its state in History. Inspect the resulting Products records before importing more data or treating the task as successful.

Sources

Last updated on September 8, 2026

Was this page helpful?