CSV Encoding Detector

Reads an uploaded file's raw bytes and reports its best-guess text encoding by checking for a UTF-8 or UTF-16 byte order mark, then attempting a strict UTF-8 decode; a decode failure indicates the file likely uses a legacy single-byte encoding such as Windows-1252 or Latin-1. A free online tool from Staaarter, right in your browser.

Runs locallyUpdated 2026-07-26

Overview

Introduction

A CSV file that looks fine in one editor can turn into garbled text the moment it's opened somewhere that assumes a different byte encoding. Figuring out which encoding a file actually uses, before importing it, saves a lot of guesswork.

This tool reads a file's raw bytes and reports its best-guess encoding, along with a preview of the decoded text so you can confirm it looks right.

What Is CSV Encoding Detector?

A file encoding detector that checks an uploaded file's raw bytes for a byte order mark (BOM), then falls back to a strict UTF-8 decode attempt to guess whether the file is UTF-8, UTF-16, or a legacy single-byte encoding like Windows-1252/Latin-1.

It runs entirely client-side as part of this site's String Tools collection; the file's bytes are read and inspected in your browser and are never uploaded to a server.

How CSV Encoding Detector Works

The tool first checks the file's first two or three bytes against the known UTF-8 BOM (EF BB BF), UTF-16 LE BOM (FF FE), and UTF-16 BE BOM (FE FF) signatures. If one matches, the rest of the file is decoded accordingly and reported.

If no BOM is present, the tool attempts a strict UTF-8 decode using the browser's TextDecoder with fatal error mode enabled. If that decode succeeds, the file is reported as UTF-8 with no BOM. If it throws, meaning the byte sequence isn't valid UTF-8, the tool reports that the file is likely Windows-1252 or Latin-1 and decodes it that way for the preview.

When To Use CSV Encoding Detector

Use it before importing an unfamiliar CSV or text file into a tool that requires a specific encoding, or when a file displays garbled accented characters and you need to know why.

It's a fast way to get the answer without opening a hex editor or writing a one-off script just to check a file's bytes.

Features

Advantages

  • Inspects actual raw bytes rather than guessing from already-decoded text, which is the only reliable way to detect a BOM or distinguish valid from invalid UTF-8.
  • Checks all three common BOM signatures (UTF-8, UTF-16 LE, UTF-16 BE) before falling back to a decode-attempt heuristic.
  • Shows a decoded text preview immediately, so you can visually confirm the guess looks right.

Limitations

  • The Windows-1252/Latin-1 fallback is a best guess triggered whenever strict UTF-8 decoding fails; it cannot distinguish Windows-1252 from Latin-1 or from other legacy single-byte encodings (such as Windows-1250 or ISO-8859-15), since many of those encodings assign different characters to the same byte values.
  • A file can coincidentally contain byte sequences that are technically valid UTF-8 even though it was actually written in a different encoding, in which case this tool will report UTF-8 incorrectly; always sanity-check the decoded preview.

Examples

Detecting a UTF-8 byte order mark

Input

Raw bytes: EF BB BF 69 64 2C 6E 61 6D 65 (a CSV file starting "id,name" with a UTF-8 BOM)

Output

Detected encoding: UTF-8 (with BOM)
Decoded preview: id,name

The first three bytes match the UTF-8 BOM signature, so the tool strips them and decodes the remainder as UTF-8.

Best Practices & Notes

Best Practices

  • Always check the decoded text preview, not just the reported encoding label, since the Windows-1252 fallback is a heuristic rather than a certainty.
  • If a file is reported as likely Windows-1252/Latin-1 but the preview still looks wrong, try a different legacy encoding in a spreadsheet or text editor that lets you pick one explicitly.
  • Re-save files as UTF-8 without a BOM where possible, since it's the most broadly compatible encoding across modern tools.

Developer Notes

Detection order is: 3-byte UTF-8 BOM (EF BB BF) → 2-byte UTF-16 LE BOM (FF FE) → 2-byte UTF-16 BE BOM (FE FF) → `new TextDecoder("utf-8", { fatal: true }).decode(bytes)`, catching the thrown error to fall back to `new TextDecoder("windows-1252").decode(bytes)`. The BOM bytes themselves are stripped from the decoded preview.

CSV Encoding Detector Use Cases

  • Diagnosing why a CSV file shows garbled accented characters after opening it in a particular tool
  • Checking whether a file exported from Excel has a UTF-8 BOM that might trip up a strict downstream parser
  • Verifying a file's encoding before writing an import script that assumes a specific one

Common Mistakes

  • Assuming every text file is UTF-8 by default; many legacy exports, especially from older Windows tools, are still Windows-1252.
  • Ignoring a UTF-8 BOM and feeding the raw file (BOM included) into a strict parser, which can cause the first field name in a CSV header to be misread.

Tips

  • If your downstream tool chokes on a BOM, use the BOM Detector and Remover on the decoded text preview to strip it.
  • When in doubt after seeing the Windows-1252 fallback, try opening the file in a spreadsheet application with an explicit "import with encoding" option to compare.

References

Frequently Asked Questions