Off Cloud by Design
Practical guides

Convert a Windows-1252 file to UTF-8 without changing its line endings

A byte-by-byte example for preserving accents, the euro sign and CRLF when converting a local text file to UTF-8.

Start with the original bytes

The encoding inspector and UTF-8 converter reads a local file before another program decodes it. Choose the original export rather than copying garbled text from an editor. A file can have valid UTF-8 bytes without proving that UTF-8 was its intended encoding.

A small, reproducible example

Select Load a Windows-1252 example. The synthetic file contains exactly eight bytes: 43 61 66 E9 20 80 0D 0A. Windows-1252 is selected explicitly. The expected Unicode text is Café €\r\n: the final notation means an actual CR followed by LF, not four literal characters.

The Unicode code points are U+0043 U+0061 U+0066 U+00E9 U+0020 U+20AC U+000D U+000A. UTF-8 cannot decode the original bytes strictly: E9 is not followed by the required continuation bytes. This is a reason to consult the source encoding, not evidence that every such file is Windows-1252.

  1. Keep Windows-1252 selected and click Preview conversion.
  2. Check that the preview reads Café €, with one CRLF and a final line break in the details.
  3. Leave the output BOM unchecked unless your receiving application explicitly requires it.
  4. Download the UTF-8 file. Its exact eleven bytes are 43 61 66 C3 A9 20 E2 82 AC 0D 0A.
  5. With the BOM option checked, preview again: the output has fourteen bytes, starting with EF BB BF before those eleven bytes.

Why “ANSI” is not enough information

An application’s “ANSI” label is ambiguous. Windows-1252 maps byte 80 to the euro sign; ISO-8859-1 maps it to U+0080, a C1 control this tool refuses. Bytes 81, 8D, 8F, 90 and 9D are undefined in this tool’s strict Windows-1252 mapping and stop conversion. Ask the export’s producer for the actual encoding rather than trying choices until text merely looks plausible.

BOM, UTF-16 and damaged endings

FF FE 41 00 0D 00 0A 00 is a UTF-16LE example with a BOM. It becomes 41 0D 0A in UTF-8 without a BOM: A plus CRLF. Without a BOM, UTF-16 must be selected explicitly. An odd final byte or an unpaired surrogate stops conversion, even beyond the visible preview. A UTF-32 BOM is recognized but refused.

What conversion preserves and cannot repair

Spaces, tabs, mixed CRLF/LF/CR endings, the presence or absence of a final newline, and composed versus combining Unicode characters are preserved. Only the initial source BOM is removed; an output BOM is your choice. If U+FFFD is already in the source, it remains there. Converting an already corrupted “Café” does not recover the original bytes.

The limit is 5 MiB (5,242,880 bytes); the preview shows at most 16,000 UTF-16 code units, while validation and export cover the whole file. Known binary signatures and NUL/C0/C1 controls other than tab, CR and LF are refused. This conservative guard may reject unusual legitimate text. Downloads use .utf8.txt and plain-text content. Your source is not overwritten.

For a CSV workflow, convert the encoding first, then use CSV to JSON to change its structure. The encoding tool itself neither parses CSV nor changes separators. Processing uses browser memory, with no tool network requests or storage; normal site requests still load pages and assets. Return to the encoding inspector to try the exact example.