Converting a file to UTF-8 without a byte-order mark (BOM) means producing clean UTF-8 bytes where no 0xEF 0xBB 0xBF prefix is written to the output, even if the source file had one. The UTF-8 Converter handles this conversion locally in your browser: it decodes your chosen source bytes with fatal error checking, consumes any leading BOM the source declares, and re-encodes the decoded characters into UTF-8 without adding a BOM back. This is the standard recommended approach for source code, configuration files, and many CSV pipelines, because a stray BOM shows up as a phantom character in places that do not expect it — the first column header of an imported CSV, the start of a JSON document, or the first three bytes of a script. The tool supports four source encodings — UTF-8, UTF-16 little-endian, UTF-16 big-endian, and Windows-1252 — and it requires you to pick one explicitly rather than guess.
What UTF-8 With and Without BOM Actually Means
UTF-8 is the dominant text encoding on the web and across modern operating systems. The Unicode Standard does not require a byte-order mark in UTF-8 — UTF-8 has a fixed byte order, so a BOM carries no information about endianness the way it does in UTF-16. When the three bytes 0xEF 0xBB 0xBF appear at the very start of a file, they declare "this is UTF-8," but any conformant decoder must also accept UTF-8 without that prefix.
Some applications save UTF-8 files with a BOM by default. Windows Notepad in particular has historically written a UTF-8 BOM unless told otherwise, and certain CSV exporters do the same so that spreadsheet programs open the file cleanly. The trouble is that tools expecting raw UTF-8 treat those three bytes as part of the first character. The string "name" can end up looking like "\ufeffname" after parsing, the first column header of a CSV becomes "\ufeffname", and shell scripts choke on the leading bytes when a shebang line is supposed to be the very first thing in the file. This is why the RFC 3629 definition of UTF-8 recommends against using a BOM except where a protocol explicitly requires one.
Converting "to UTF-8 BOM" therefore has two distinct meanings, and they produce opposite results. If your destination needs the BOM — for example, a downstream parser that checks for 0xEF 0xBB 0xBF — you want bytes that start with those three values. If your destination expects raw UTF-8 — source repositories, JSON consumers, most Linux tooling — you want no prefix at all. The UTF-8 Converter targets the second case: it strips a recognized BOM and never writes a new one.
Choose the Right Source Encoding Before You Convert
The hardest part of any encoding conversion is identifying what produced the bytes in the first place. Most modern applications document their default — Visual Studio on Windows used to write UTF-16 with BOM, Notepad still defaults to UTF-8 with BOM, Java source files commonly come out as UTF-8 without BOM — and that documentation is the most reliable answer. Look for "encoding," "charset," or "default save format" in the producing application's settings or the file's own metadata before guessing.
| Source Encoding | Commonly Produced By | BOM Handling |
|---|---|---|
| UTF-8 | Most modern editors, web exports, Linux tooling | Leading BOM consumed, output has no BOM |
| UTF-16 little-endian | Windows Notepad "Unicode", some Java and .NET streams | Matched BOM recognized and removed |
| UTF-16 big-endian | Network byte-order exports, some Unix archives | Matched BOM recognized and removed |
| Windows-1252 | Legacy Western European text, often mislabeled ISO-8859-1 | No BOM concept; bytes re-encoded into UTF-8 |
Byte sequences can be valid under more than one legacy encoding while representing different characters. The byte 0x80 means "€" in Windows-1252 but is undefined in ISO-8859-1, and the same byte appears in a UTF-16 stream as part of a two-byte code unit. An automatic guess can therefore look plausible and still corrupt names, punctuation, or symbols. Explicit selection keeps the transformation auditable: you can point at the source application and say "this is what wrote the file," then verify the preview against a known-good sample.
Convert a File to UTF-8 Without BOM Using the Browser Tool
- Identify the source encoding. Check the application that produced the file, the platform's default save format, or any reliable metadata. Do not rely on visual inspection of glyphs alone — many encodings render plausibly until they hit a name, a quotation mark, or a currency symbol.
- Open the UTF-8 Converter and select the matching source encoding. Pick UTF-8, UTF-16LE, UTF-16BE, or Windows-1252 from the encoding selector based on what you confirmed. Switching the selector after a file is loaded resets the preview, so set it first.
- Choose the text file up to 10 MB. The size is checked before the file is read, so an unexpectedly large file is rejected without loading. Multi-gigabyte logs and database dumps should use a streaming tool instead.
- Convert and inspect the preview. The browser decodes the bytes with the WHATWG label and fatal error handling, so malformed UTF-8 sequences fail loudly instead of producing replacement diamonds. Check representative names, punctuation, currency symbols, and any non-ASCII line before you trust the result.
- Download the converted file. The output is exposed as a local Blob URL with a UTF-8 media type and a filename ending in -utf8. The downloaded bytes contain no BOM, so the file is ready for source repositories, JSON consumers, and Linux tooling that expect raw UTF-8.
- Test the result in the destination application. Open the downloaded file where it will actually be used — the IDE, the data pipeline, the web server — and confirm the preview matches. Retain the original until the full workflow is verified.
Reading the Preview to Catch Encoding Errors
The preview is the cheapest place to catch a wrong encoding choice. Look at lines you already understand in the source — a customer name with diacritics, a sentence with curly quotation marks, a row containing a euro sign — and compare them against what you expect. If curly quotes come back as straight quotes, you almost certainly picked the wrong code page. If emoji render as two boxed glyphs, you likely picked a single-byte encoding for a UTF-16 source. The page also reports the source and output byte counts; different counts are expected and do not by themselves indicate data loss because UTF-8 uses more bytes than Windows-1252 for anything above U+007F.
A concrete worked example illustrates the re-encoding. Take the Windows-1252 byte 0x80, which by the standards-defined Windows-1252 decoder maps to the euro sign U+20AC. Under fatal decoding, that single byte becomes the Unicode scalar value U+20AC, which the UTF-8 encoder then writes as the three bytes 0xE2 0x82 0xAC. So a one-byte euro in a Windows-1252 file becomes a three-byte euro in a UTF-8 file: 1 → 3 bytes, an expansion that is correct and not corruption.
Verifying the Downloaded File in the Destination App
Once the converted file is on disk, treat it as a candidate until you have tested it. Open it in the application that will read it day to day and run a sanity pass: a build that compiles, a database import that succeeds, a CSV import that produces correct headers, a JSON parser that does not reject the first byte. If you maintain source code, run the project's existing test suite — silent encoding bugs often surface as a single failed assertion on a string comparison far from the actual byte that changed.
The filename ending in -utf8 helps you keep the original alongside the new file during the verification window. Once you are confident the workflow is correct, the original can be retired. For Notepad users who specifically need UTF-8 with BOM, the converter does not add one back; in that case the Notepad-specific workflow covers the opposite case. For Windows-level file associations, the Windows encoding guide walks through the broader system settings.
When a Streaming Tool Is the Better Choice
The 10 MB limit exists because the converter keeps the full file in an in-memory buffer while it decodes and re-encodes. For typical source files, configuration data, CSV exports, and small logs that limit is comfortable. For multi-gigabyte log archives, database dumps, or media subtitles, you want a streaming converter that reads source bytes and writes destination bytes without holding the entire file in RAM. Pick a tool that still requires you to name the source encoding explicitly — the same auditable principle applies — and that reports progress so you can spot a stalled job early.
The converter's role is intentionally narrow: real file bytes, one of four declared source encodings, fatal validation, a downloadable UTF-8 artifact without a BOM. It does not detect encodings heuristically, repair mojibake, normalize Unicode, translate languages, or change line endings beyond what follows from decoding into characters and re-encoding into UTF-8. For everything outside that scope — BOM-on output, automatic detection, mojibake repair, supplementary normalization — reach for the appropriate specialized tool rather than expecting one utility to cover every encoding job.