Can the tool detect my file encoding?

No. Encoding detection is probabilistic; this tool requires an explicit source encoding for an auditable conversion.

Why did the byte count change after conversion?

Different encodings use different byte lengths for the same characters, so a correct UTF-8 conversion often changes file size.

Does the output include a UTF-8 BOM?

No. A recognized source BOM is consumed and the downloaded UTF-8 bytes are emitted without adding one.

What happens to a UTF-8 source file that already has a BOM?

The leading EF BB BF is consumed by the standards-based decoder, so the downloaded file begins with the first real character.

Can I convert files larger than 10 MB?

No. The browser in-memory buffer caps the size at 10 MB before reading. For larger files use a trusted streaming conversion utility.

Convert to UTF-8 Without BOM by Selecting the Source Encoding

Converting a file to UTF-8 without a BOM means producing a UTF-8 byte stream that starts exactly with the first character of the text rather than the three-byte marker EF BB BF. The safest path is to identify the encoding that actually wrote the file, decode the bytes with strict validation, and re-encode through a standards-defined UTF-8 encoder that does not prepend one. UTF-8 Converter follows exactly that workflow: it reads a local text file, decodes it under the encoding you choose, previews the non-ASCII content, and downloads a fresh file whose bytes begin at the first decoded character. Because the WHATWG encoding decoder and the browser File API do the work in memory, the source bytes never leave your device, which matters when the file holds names, internal notes, or code that you do not want uploaded anywhere. The downloaded file is emitted with a plain-text media type and a filename that appends -utf8 to the original.

Why a UTF-8 BOM Trips Up Real Workflows

The UTF-8 byte-order mark is the byte sequence EF BB BF. The marker exists because Unicode lets UTF-8 files carry a BOM for symmetry with UTF-16, but for an 8-bit encoding it carries no useful information: UTF-8 has no byte order to advertise, and the first code point is unambiguously identifiable without a prefix. A handful of Windows editors add the BOM anyway whenever a user picks "Save as UTF-8", which is why a clean text file can suddenly fail in tools that never expected three invisible bytes at the start.

PHP rejects a leading BOM at the top of a source file because it is treated as output, and SQL parsers built on strict UTF-8 read it as an unexpected character that may break the first identifier. Unix toolchains such as grep, awk, and shell pipelines often pass those three bytes through to scripts that do not expect them. JSON, YAML, and CSV consumers that strip or validate the first byte will either throw a parse error or insert a stray character into the first field. Even Python 3 source code compiled with a UTF-8 BOM works, but Python 2 historically refused it, and many third-party parsers still do. The UTF-8 Converter addresses this directly: a recognized source BOM is consumed by the standards-based decoder, and the downloaded result is emitted by the UTF-8 encoder without adding a BOM.

Why the Tool Refuses to Guess the Encoding

The single most important rule when you convert a file to UTF-8 without a BOM is that the source encoding must be selected explicitly. Byte sequences can be valid under more than one legacy encoding while representing different characters, so an automatic guess can look plausible and still corrupt names, punctuation, or symbols. UTF-8 Converter does not detect encodings for this reason: it requires you to pick the one that wrote it so the transformation stays auditable. If the wrong encoding is chosen, the preview will usually reveal scrambled characters before you commit to the download, and you can switch the source selection and reconvert without re-uploading the file.

The conversion is local. The browser reads the file through the File API, decodes it with the WHATWG encoding label you selected, re-encodes the result with the browser UTF-8 encoder, and exposes the bytes through a revocable Blob URL. The original file stays on disk and is untouched until you choose to replace it.

Convert a File to UTF-8 Without a BOM

Determine and select the file's real source encoding instead of guessing from its appearance. Check the producing application, the file's documented origin, or any reliable metadata that records the encoding that wrote the bytes.
Choose a text file up to 10 MB, convert it, and inspect non-ASCII characters in the preview. The preview decodes the bytes under the selected source encoding, so any obviously wrong choice will show up here.
Download the UTF-8 file, test it in the destination application, and retain the original until verified. The downloaded file is emitted by the UTF-8 encoder without a BOM, so it begins at the first character of the decoded text.

Source Encodings the Tool Handles

The four supported source encodings cover the formats most readers meet in practice. Each one has different byte layouts, and selecting the wrong one will produce a file that decodes fine but renders to different glyphs than the original.

Source encoding	When to pick it	BOM behavior with this tool
UTF-8	The file was saved as UTF-8, possibly with a leading BOM. Validation is strict: invalid continuation bytes, truncated sequences, and forbidden encodings cause a clear failure rather than replacement characters.	A leading UTF-8 BOM (EF BB BF) is consumed by the decoder. The output has no added BOM.
UTF-16LE	Low byte stored first, common in Windows tools and many Unix text files saved by certain runtimes.	A matching FF FE BOM is recognized and removed during decoding; the output has no BOM.
UTF-16BE	High byte stored first, common in older Java artifacts, network protocols, and big-endian dumps.	A matching FE FF BOM is recognized and removed during decoding; the output has no BOM.
Windows-1252	Western European legacy code page, often mislabeled ISO-8859-1. Bytes 80 through 9F include printable punctuation and symbols such as the euro sign and curly quotation marks.	No source BOM. Output represents decoded characters re-encoded as UTF-8, not a byte-for-byte copy.

How a Source BOM Is Handled for Each Encoding

UTF-8 BOM handling is the headline case: a leading EF BB BF is treated as a marker, consumed by the standards-based decoder, and discarded so the downloaded file begins with the first real character. UTF-16LE and UTF-16BE modes differ in byte order. The letters in a file can become nonsense if endian order is reversed even though pairs of bytes remain readable. Select little-endian for formats that store the low byte first and big-endian for formats that store the high byte first. A matching BOM is recognized and removed. Supplementary characters such as emoji use UTF-16 surrogate pairs, and the tool combines a valid high and low surrogate into one Unicode scalar value before producing UTF-8 output. Unpaired or malformed sequences are rejected under fatal decoding, which prevents silently exporting replacement diamonds while claiming a successful conversion.

What the Preview Catches and What It Does Not

The preview is a quick visual check that the decoded characters look right. Read representative lines: names with accents, punctuation like curly quotes or em dashes, currency symbols, and any non-ASCII lines. A wrong source encoding usually shows up immediately as garbled glyphs. The preview may not display every control character or normalization difference, so for files that mix scripts, normalize Unicode, or include invisible characters, plan a follow-up check with a hex viewer.

Different byte counts between source and output are expected and do not by themselves indicate data loss. Windows-1252 packs most characters into one byte, while UTF-8 expands many of those same characters into two or three bytes. The reverse happens with UTF-16 input: a UTF-16 surrogate pair collapses into a four-byte UTF-8 sequence. The page reports source and output byte counts so expansion or contraction is visible.

When a Single File Cannot Be Decoded Reliably

If the source contains mixed encodings in one file, a single decoder cannot repair it reliably. Examples include a Windows-1252 CSV with stray UTF-8 rows pasted from a web export, or a UTF-8 source file where someone replaced one paragraph by pasting bytes from a Windows editor without re-encoding. Split the file along the boundary, convert each segment with the right source encoding, then concatenate the decoded text rather than the raw bytes. The same principle applies to control characters and line-ending drift: they are preserved as decoded characters, but the converter does not normalize Unicode or modify line endings beyond what follows from decoding and UTF-8 encoding.

When the 10 MB Limit Means You Need a Different Tool

Files are limited to 10 MB because the browser File and Encoding interfaces operate on an in-memory buffer here. The size is checked before reading to avoid loading an unexpectedly large file. For database dumps, multi-gigabyte logs, or media manifests, use a trusted streaming conversion utility with explicit source and destination encodings, since reading the whole file into memory is not practical. The standards used here are documented in the WHATWG Encoding specification and RFC 3629, both of which define how the bytes are decoded and what a valid UTF-8 sequence looks like in the output.