When a file opens in Notepad as garbled text, the fix is to identify the file's true source encoding, decode the bytes with a standards-based decoder, and re-encode the result as UTF-8 without a byte-order mark. Notepad's Save As menu lets you pick UTF-8, but that only works correctly when the bytes on disk are already valid UTF-8. If the original file was saved as UTF-16 little-endian, UTF-16 big-endian, or Windows-1252, simply re-saving through Notepad can leave you with replacement diamonds, swapped character pairs, or wrong symbols because Notepad's reading step may silently substitute replacement characters or misread the byte order. A safer workflow uses a local tool such as the UTF-8 Converter, which decodes the selected source encoding with fatal error handling, previews the decoded text, and exports a BOM-free UTF-8 file you can verify in your destination application before replacing the original.
Why Notepad's Save As UTF-8 Often Falls Short
Notepad in modern Windows can write UTF-8, but the option is a one-step save rather than a full conversion. If the bytes on disk are already valid UTF-8, choosing File → Save As → Encoding → UTF-8 simply rewrites the same content with no visible difference. If the bytes on disk are not UTF-8, Notepad must first read them, infer an original encoding, and only then write UTF-8. That read step is where damage happens.
Files created by older Windows programs are often Windows-1252. Files exported from databases or Java tools are often UTF-16 with a leading byte-order mark. Files saved by macOS tools can be UTF-8 without a BOM. When Notepad encounters a file it cannot decode cleanly, it may silently insert replacement characters (U+FFFD, the diamond with a question mark) for every unreadable byte, or it may try to render the bytes as Windows-1252 and write the result back as UTF-8, producing a file where names, currency signs, and punctuation are now wrong even though Notepad shows no error.
Because Notepad combines the read and the write into one operation, there is no preview step, no fatal validation, and no record of what encoding was assumed. If the wrong assumption is made, the damage is committed to the new file before you see it. That is the gap a dedicated converter fills.
| Aspect | Notepad Save As > UTF-8 | UTF-8 Converter |
|---|---|---|
| Source encoding choice | Inferred during read | Selected explicitly by the user |
| Preview before write | None | Decoded text shown in browser |
| Behavior on invalid bytes | Silent replacement characters possible | Fatal validation with a clear failure message |
| Output BOM | Writes UTF-8 without a BOM by default | BOM-free output |
| File size cap | No fixed limit | 10 MB, checked before reading |
| Privacy | Local | Local, no upload |
Identify the File's Real Source Encoding First
Before any conversion can be reliable, the file's actual source encoding has to be known. Encoding detection is probabilistic. The bytes C2 A9 are valid UTF-8 for the copyright sign © and equally valid as Windows-1252 for ©, and a statistical detector will pick whichever is more common in its training data, which is not always the one your file actually used. The only safe answer comes from the producing application or from reliable metadata: a UTF-16 BOM (FF FE or FE FF), a file extension like .txt with explicit encoding notes, or a database export log that records the source charset.
For typical situations, three source encodings cover the majority of what shows up in Notepad as garbled text:
- UTF-16 little-endian with a BOM (FF FE) — common from older Windows Notepad saves and many Java and .NET exports.
- UTF-16 big-endian with a BOM (FE FF) — common from some Java tools and older Unix systems.
- Windows-1252 — common from older Windows applications, batch scripts, and CSV exports from legacy software. Bytes 80 through 9F include printable punctuation and symbols such as the euro sign and curly quotation marks.
ASCII-only files are technically valid UTF-8 because ASCII is a subset of UTF-8, so if every non-printable character is below 0x80 you usually do not need to convert at all.
Convert a File to UTF-8 in Your Browser
The following steps walk through converting a local text file to UTF-8 using a browser-based tool that decodes the bytes explicitly and never uploads them.
- Open the UTF-8 Converter in your browser. The interface reads files locally through the browser's File API, so source bytes never leave your machine.
- Select the source encoding that actually produced the file: UTF-8, UTF-16 little-endian, UTF-16 big-endian, or Windows-1252. Choosing the wrong one is the most common reason a conversion produces wrong characters, so pick based on what produced the file rather than how it looks.
- Choose the text file. The converter enforces a 10 MB ceiling before reading, so very large database dumps and multi-gigabyte logs are rejected up front; for those, use a streaming conversion utility with explicit source and destination encodings.
- Convert and inspect the preview. The decoded text appears using a standards-based decoder with fatal error handling, so invalid continuation bytes, truncated sequences, and forbidden encodings produce a clear failure rather than silent replacement characters. Look for obvious signs of a wrong selection: names that should be accented appearing as ASCII, curly quotes appearing as  followed by another character, or emoji showing up as boxes.
- Download the result. The downloaded file is re-encoded by the browser's UTF-8 encoder with no added BOM, the filename gains a -utf8 suffix, and the page reports source and output byte counts so any expansion or contraction is visible.
- Open the new file in your destination application and verify that names, punctuation, currency symbols, and any non-ASCII lines render correctly. Only then replace the original. Keep the original file until the complete workflow is verified.
Changing the file or source encoding in the interface cancels the visible result and invalidates the prior download link, so a slow older read cannot replace a newer choice and obsolete object URLs are revoked.
Source Encodings the Converter Supports
The converter covers four source encodings, each with different failure modes when handled casually.
| Source encoding | Typical origin | BOM behavior | Common failure if treated as UTF-8 |
|---|---|---|---|
| UTF-8 (validated) | macOS saves, modern editors, web exports | Leading UTF-8 BOM consumed if present | None when file is valid; malformed UTF-8 is rejected under fatal decoding |
| UTF-16 little-endian | Legacy Windows Notepad, Java and .NET exports | BOM FF FE recognized and removed | Letters become nonsense; pairs of bytes remain readable but represent wrong characters |
| UTF-16 big-endian | Some Java tools, older Unix systems | BOM FE FF recognized and removed | Same nonsense output as little-endian, just the opposite byte order |
| Windows-1252 | Older Windows apps, legacy CSV exports | No BOM | Bytes 80-9F are not valid UTF-8 start bytes and cause a fatal decoding error |
Supplementary characters such as emoji are handled inside UTF-16 modes by combining a valid high and low surrogate into one Unicode scalar value before UTF-8 output, per the WHATWG Encoding Standard. Unpaired or malformed surrogate sequences are rejected under fatal decoding so the converter never silently exports replacement diamonds while reporting success. For Windows-1252, the standards-defined decoder maps bytes 80 through 9F to their printable forms (euro sign, curly quotes, en dash, em dash, and similar) before re-encoding, so the output represents decoded characters rather than a byte-for-byte copy. The euro byte 80, for example, becomes the three UTF-8 bytes E2 82 AC.
Different byte counts between source and output are normal and expected. UTF-8 uses one to four bytes per character, Windows-1252 uses one, and UTF-16 uses two or four. A correct conversion will usually grow ASCII-heavy Western European files by a small amount and roughly hold or shrink files originally written in a wide legacy code page. The reported source and output byte counts let you see the change directly, and different counts alone do not indicate data loss.
Verify the Result and Keep the Original
The preview pane is meant to catch obviously wrong selections before download. Scan it for representative names, punctuation, currency symbols, and any non-ASCII lines you expect to see. If a name like Müller appears as Müller, the source encoding is almost certainly UTF-8 over-decoded as Latin-1. In that case re-run the conversion with the correct source encoding rather than treating the preview as final output.
Some details cannot be checked from a preview alone. Control characters may not render visibly, normalization differences (such as NFC versus NFKC) will not appear, and a mixed-encoding file cannot be repaired by selecting a single source decoder. For genuinely mixed files, separate the content by encoding first or contact the producer for a clean export. The converter is also distinct from a text-to-UTF-8-byte viewer: it operates on real file bytes, takes an explicit legacy encoding, and produces a downloadable artifact rather than hex or binary output.
Once the preview looks right, download the file and test it inside the application that originally misbehaved. Open it there, confirm the characters look correct, and only then overwrite the original. The browser revokes the local download URL when the job is replaced, and the in-memory buffer is per-file rather than per-session, so an old result cannot quietly return. Keeping the original until the full workflow is verified is a small habit that prevents a lot of irreversible damage to source data.
For a deeper look, see How to Use a UTF-8 Encoder / Decoder.