Changing a file's encoding to UTF-8 means decoding its bytes under the encoding that originally wrote them and re-encoding the resulting characters as UTF-8. The source bytes are not rewritten in place; they are first interpreted as characters through the source encoding, and those characters are then serialized into UTF-8 bytes for the output file. If the source encoding is wrong, the characters change meaning — names, punctuation, and symbols become mojibake even when the bytes themselves look syntactically plausible. The cleanest path is therefore to know the encoding the file was produced in, decode with that exact label, and emit UTF-8 from the resulting Unicode characters. A browser-based tool can carry out this conversion without uploading the file, which keeps confidential data on the local machine. The UTF-8 Converter does exactly this: it reads local files, previews the decoded characters, and exports a downloadable BOM-free artifact. Validation during decoding matters too: invalid byte sequences and truncated multibyte runs should fail loudly rather than be replaced with replacement characters, because silent substitution produces a file that opens without error yet misrepresents the original text.
What "Changing a File's Encoding to UTF-8" Actually Does
Every text file is a sequence of bytes plus a convention for turning those bytes into characters. UTF-8, UTF-16 little-endian, UTF-16 big-endian, and Windows-1252 are four such conventions that you will encounter on real data. Changing the encoding therefore requires two stages: read the bytes as characters using the convention that produced the file, then write those characters back out using UTF-8. The output file is a brand-new byte sequence, not a header-flipped copy of the input.
Because UTF-8 uses one to four bytes per character depending on the code point, the output file size usually changes. Pure ASCII inputs become byte-identical, since ASCII characters are encoded as a single byte in both legacy ASCII-compatible encodings and UTF-8. Anything outside ASCII — accented letters, Cyrillic, CJK characters, emoji — becomes two, three, or four UTF-8 bytes. That expansion is normal and expected, not a sign of damage.
Why the Source Encoding Must Be Selected Explicitly
The most common cause of mojibake is not a broken tool but an assumed source encoding. Many byte sequences are valid under more than one legacy encoding while representing different characters. A single byte such as 0x95 decodes to U+2014 (em dash) under Windows-1252 and to a control character under ISO-8859-1. If a heuristic picks the wrong label, the output file will open without any visible warning, yet names, punctuation, and symbols will silently change.
This is why a tool that requires an explicit source encoding is safer than one that guesses. An auditable conversion records what was assumed: when the result looks wrong, the assumption can be revisited and the conversion redone with a different source label, instead of being locked inside an opaque detection step. UTF-8 mode takes this further with fatal validation, as defined by the WHATWG Encoding Standard: invalid continuation bytes, truncated sequences, and forbidden byte ranges cause a clear failure rather than replacement characters. A failed conversion is far easier to debug than a quietly corrupted one.
Source Encodings the Converter Handles
Four source encodings cover the great majority of text files you will need to convert. The table summarizes their distinguishing traits.
| Encoding | Typical source | BOM handling | Byte-order note |
|---|---|---|---|
| UTF-8 | Cross-platform exports, modern applications, web content | A leading BOM is consumed by the decoder; output is emitted without one | Not applicable |
| UTF-16 little-endian | Windows Notepad "Unicode" saves, many Windows APIs | Recognized BOM (FF FE) is stripped before output | Low byte first; reversal scrambles text |
| UTF-16 big-endian | Some Unix and Java exports, network protocols | Recognized BOM (FE FF) is stripped before output | High byte first; reversal scrambles text |
| Windows-1252 | Legacy Western European files often mislabeled ISO-8859-1 | No BOM concept | Single-byte; bytes 0x80–0x9F are printable punctuation and symbols |
A Windows-1252 euro byte 0x80 becomes the three UTF-8 bytes E2 82 AC after a correct conversion. Supplementary characters such as emoji are encoded as UTF-16 surrogate pairs; a valid high surrogate followed by a valid low surrogate is combined into one Unicode scalar value before UTF-8 output, and unpaired or malformed pairs fail decoding. The byte layout of the output is specified in RFC 3629.
Change a File's Encoding to UTF-8 in Three Steps
- Identify the real source encoding. Check the producing application's save dialog, the file's metadata, or any documentation that came with it. Do not rely on what the file looks like in a text editor, because a guessed wrong label will still produce readable text with corrupted characters.
- Open the UTF-8 Converter, pick the matching source encoding from the selector, and choose the text file (up to 10 MB). The browser reads the bytes locally and decodes them under the selected label with fatal error handling. The preview pane shows the decoded characters, which lets you verify a representative sample of names, punctuation, currency symbols, and non-ASCII lines before downloading.
- Download the result. The filename has -utf8 appended and the bytes are BOM-free UTF-8. Open the new file in the destination application and confirm that special characters look correct. Keep the original file until the full workflow has been verified end to end.
Reading the Preview and Byte Counts
The preview is the cheapest place to catch a wrong source encoding. If a file was saved from a French Windows installation as Windows-1252 and you accidentally select UTF-16LE, the preview will show scrambled characters or replacement boxes where accented letters should be. Selecting Windows-1252 instead usually reveals the correct accented text immediately.
The page also reports source and output byte counts. These will differ for most realistic inputs because UTF-8 uses more bytes per character than single-byte legacy encodings for non-ASCII characters. A larger output is normal and does not by itself indicate data loss; a smaller output would be unusual and worth investigating. The preview can miss some control characters and Unicode normalization differences, so treat it as a quick sanity check rather than a complete verification. Open the downloaded file in the actual application that will consume it, and test a known sample of non-ASCII content end to end.
Limits and When to Use a Different Method
The converter is sized for browser in-memory processing, with a 10 MB file cap checked before the read begins. Files larger than that should go through a streaming utility with explicit source and destination encodings — for example, command-line iconv, PowerShell's Get-Content and Set-Content with an Encoding parameter, or a database import/export that takes encoding parameters. Multi-gigabyte log archives and database dumps fall into this category. Readers who need to set UTF-8 as the system-wide default for Windows text files can follow the platform-specific steps in this Windows UTF-8 guide.
A single file that mixes encodings cannot be repaired by one decoder pass. If a CSV has some columns saved as UTF-8 and others pasted from a Windows-1252 source, the only reliable fix is to return to the original data source and re-export each piece under a single known encoding. The converter also cancels the visible result and invalidates the prior download URL whenever the file or source encoding changes, so a slower stale read cannot replace a newer choice. Revoked object URLs are not retrievable.
The Core Workflow in One Paragraph
Changing a file's encoding to UTF-8 is a two-stage operation that depends entirely on identifying the source encoding correctly. The UTF-8 Converter carries that out locally: explicit source selection, fatal validation, BOM-free output, and a downloadable artifact up to 10 MB. For routine single-file conversions on text in UTF-8, UTF-16LE, UTF-16BE, or Windows-1252, that is the entire workflow. For larger files, mixed-encoding sources, or batch conversions, switch to a streaming tool whose source and destination encodings you can specify on the command line.
Related reading: Base100 Encode Large Text: UTF-8 Expansion and Limits.