How is this different from the CSV to Base64 converter?

CSV to Base64 always encodes the UTF-8 bytes of your text and only changes the text representation (Base64 vs. plain text). This tool changes the actual character encoding of the bytes themselves, UTF-8, UTF-16LE, UTF-16BE, or windows-1252, which matters when a downstream system expects a specific encoding, not just UTF-8.

Why is the visible output shown as Base64 instead of plain text?

UTF-16 and windows-1252 byte sequences generally aren't valid UTF-8, and JavaScript strings (and HTML textareas) are fundamentally UTF-16/Unicode text containers, so there's no clean, lossless way to display arbitrary re-encoded bytes as one plain string. Base64 sidesteps that by representing the exact bytes using only safe, copyable ASCII characters.

Is the copied Base64 text the same thing as the downloaded file?

No. The Base64 text you copy is a text-safe representation of the re-encoded bytes, useful for pasting into another tool or a script. The downloaded file contains those same bytes directly, in raw binary form, ready to be opened by an application expecting that encoding.

What happens if a character can't be represented in windows-1252?

Windows-1252 is a single-byte encoding covering only a few hundred characters, mostly Western European. If your CSV contains a character outside that set (most CJK characters, most emoji, many other scripts), the tool reports exactly which character and its Unicode code point instead of silently substituting or dropping it.

Does adding a byte-order-mark (BOM) work for every encoding?

BOM is meaningful, and offered, for UTF-8 (EF BB BF), UTF-16LE (FF FE), and UTF-16BE (FE FF). Windows-1252 has no standard byte-order-mark convention, so the BOM option has no effect when that encoding is selected.

Why would I ever need UTF-16 or windows-1252 instead of just UTF-8?

Some legacy systems, older Windows applications, and specific CSV import tools (a well-known example being Excel on Windows, which sometimes expects UTF-16LE with a BOM, or a Western European windows-1252 file) expect one of these specific encodings rather than UTF-8, and will misinterpret or mangle accented characters otherwise.

CSV Encoding Converter - UTF-8, UTF-16, Windows-1252

Overview

Introduction

CSV files aren't just rows and columns, they're also a specific sequence of bytes, and which character encoding those bytes use matters a great deal to whatever opens the file next. A CSV saved as UTF-8 can look like garbled text ("mojibake") when a tool expects windows-1252, or vice versa.

This tool re-encodes your CSV's underlying bytes into whichever of the common encodings your destination system actually expects, UTF-8, UTF-16LE, UTF-16BE, or windows-1252/Latin-1, and lets you add or remove a byte-order-mark.

What Is CSV Encoding Converter?

A character-encoding converter for CSV text: it takes the CSV as a JavaScript string (already valid Unicode) and re-encodes it into the raw byte sequence a specific target encoding would produce, rather than changing the delimiter or structure at all.

Because some target encodings can't be shown as one clean JavaScript string, the visible result is a Base64 representation of the exact bytes, with a real download available in the true target encoding.

How CSV Encoding Converter Works

For UTF-8, the browser's built-in `TextEncoder` produces the bytes directly. For UTF-16LE and UTF-16BE, since no browser API encodes to UTF-16 bytes, this tool manually writes each UTF-16 code unit of the JavaScript string as two bytes, in the chosen byte order. For windows-1252, it maps each character's Unicode code point to its single-byte windows-1252 equivalent using a lookup table for the small set of characters (like curly quotes and the Euro sign) that differ from plain Latin-1 in that range.

If a byte-order-mark is requested, the appropriate 2- or 3-byte BOM sequence is prepended (this has no effect for windows-1252, which has no BOM convention). The final bytes are then Base64-encoded for on-screen display and copying, and made available as a real downloadable file in the target encoding.

When To Use CSV Encoding Converter

Use it when a specific system, an older Windows application, a particular database import tool, or a partner's specified format, requires CSV in a named encoding other than UTF-8.

It's also useful for testing how your CSV data behaves across encodings, for example, checking whether all your characters are actually representable in windows-1252 before committing to that format.

Often used alongside CSV to Base64 Converter, Base64 to CSV Converter and CSV Delimiter Changer.

Features

Advantages

Supports the encodings most commonly required by legacy or Windows-oriented tooling: UTF-8, UTF-16LE, UTF-16BE, and windows-1252.
Clearly reports the specific unsupported character and its Unicode code point when windows-1252 encoding fails, rather than silently corrupting data.
Produces a real, correctly-encoded downloadable file, not just a text preview, so the output is directly usable by the target system.

Limitations

Windows-1252 can only represent a few hundred characters total; CSV containing CJK text, most emoji, or many other non-Western scripts cannot be represented in it at all.
The on-screen textarea shows Base64 of the encoded bytes, not the encoded text itself, since UTF-16 and windows-1252 byte sequences generally aren't valid UTF-8 and can't be shown as one clean JavaScript string.

Supported target encodings

Supported target encodings
Encoding	Bytes per character	BOM support	Typical use
UTF-8	1-4 (variable)	Optional (EF BB BF)	Web, modern APIs, most current tooling
UTF-16LE	2 (or 4 for surrogate pairs)	Optional (FF FE)	Older Windows applications, some Excel imports
UTF-16BE	2 (or 4 for surrogate pairs)	Optional (FE FF)	Some Java/network protocols, less common on desktop
windows-1252	1 (fixed)	Not applicable	Legacy Western European Windows systems

Examples

Re-encoding a small CSV to UTF-16LE with a BOM

Input

id,name
1,Ada Lovelace

Output

//9pAGQALABuAGEAbQBlAAoAMQAsAEEAZABhACAATABvAHYAZQBsAGEAYwBlAA==

The Base64 preview represents the FF FE byte-order-mark followed by each character encoded as two little-endian bytes; the actual downloadable file contains these exact bytes.

Best Practices & Notes

Best Practices

Before committing to windows-1252, run your CSV through this tool once to surface any character it can't represent, rather than discovering it downstream as corrupted data.
When a Windows application specifically asks for a BOM, include one for that encoding, its absence is a common cause of "the accented characters look wrong" bug reports.
Use the downloaded file for actually opening in the target application; treat the copied Base64 text as a preview or intermediate transport format, not the final artifact.

Developer Notes

Browsers only expose `TextEncoder` for producing UTF-8 bytes, there's no built-in browser API to encode a JS string into UTF-16LE/BE or windows-1252 bytes (only `TextDecoder` can read those encodings back into a JS string). UTF-16 encoding is done manually here by iterating `charCodeAt` (UTF-16 code units, so surrogate pairs for astral characters are naturally handled as two code units, two 2-byte writes) and writing each as 2 bytes in the requested byte order. Windows-1252 encoding uses a hand-written reverse lookup table for the ~27 code points in the 0x80-0x9F range where it diverges from plain Latin-1/ISO-8859-1, since those are exactly the printable characters (curly quotes, em/en dashes, the Euro sign) most likely to appear in real CSV text and most likely to trip up a naive Latin-1 assumption.

CSV Encoding Converter Use Cases

Preparing a CSV file for import into a legacy Windows application that expects UTF-16LE with a BOM
Converting a CSV export to windows-1252 for a system that doesn't support Unicode encodings at all
Verifying which characters in a dataset aren't representable before committing to a legacy, non-Unicode encoding

Common Mistakes

Copying the visible Base64 text and saving it directly as the CSV file, the Base64 text is a preview/transport format, the actual re-encoded bytes are in the downloaded file, not in decoding the copied text yourself.
Expecting windows-1252 to support arbitrary Unicode text; it's a small, fixed single-byte charset and will reject characters outside its coverage rather than approximate them.

Tips

If you're not sure which encoding a legacy system expects, UTF-16LE with a BOM is the most common default for older Windows-authored files, and windows-1252 is the most common default for older Western European Windows text files without Unicode support.
If windows-1252 encoding fails, check the reported character's code point, it's often a "smart quote", em dash, or similar punctuation mark that a word processor introduced automatically.

CSV Encoding Converter