{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Source{{ summarySource }} Target{{ encodingLabel(target_encoding) }} Output{{ summaryOutput }}
{{ sourceFile ? sourceFile.name : 'Drop one text file here' }}
{{ sourceFileSummary }}
{{ fileError || 'Maximum 2 MiB. Processing stays local to this tab.' }}
Auto uses a Unicode signature first, then strict UTF-8. Ambiguous legacy bytes require an explicit choice.
The output filename records the selected encoding.
Keep Stop unless reviewed downstream compatibility is more important than exact text preservation.
{{ workflowMessage }}
Preserve changes no signature unless the source already has one.
Preserve is neutral and leaves every existing separator untouched.
{{ previewText }}

The chart renderer is unavailable. The same byte counts remain in the conversion ledger.

DecisionApplied valueReview noteCopy
{{ row.label }}{{ row.value }}{{ row.note }}
Base64 Encoder and Decoder Encode or decode Base64 text and files locally, choose standard or URL-safe output, repair missing padding, and inspect the recovered bytes.
Comma-Separated Values (CSV) Converter Convert CSV-like text into structured formats, review row alignment and column completeness, and keep sensitive source data in your browser.
Gzip Text Decompressor Decompress gzip, zlib or raw deflate into readable text in your browser with wrapper checks, byte counts and strict encoding options.
File Hash Generator Hash one local file in your browser and compare its full digest with SHA-2 or SHA-3 plus required RIPEMD-160 and legacy references.

A text file stores bytes, while readers work with characters. An encoding supplies the mapping between those two forms. When a program guesses the wrong encoding, ordinary punctuation can become garbled, non-Latin text may disappear, and a file can appear damaged even though its original bytes are intact.

UTF-8 represents Unicode characters with one to four bytes and preserves ASCII bytes unchanged. UTF-16 uses 16-bit code units and must establish whether the least-significant or most-significant byte comes first. Windows-1252 is a legacy single-byte encoding for Western European text; it cannot represent the full Unicode range.

Byte-order mark
An optional leading signature that can identify UTF-8 or indicate UTF-16 byte order. Some consumers expect it, while others treat it as unwanted content.
Replacement character
U+FFFD marks bytes that could not be decoded as valid Unicode. A question mark may replace a Unicode character that Windows-1252 cannot encode.
Line ending
LF and CRLF are different byte sequences for line breaks. Changing them can affect diffs, shell scripts, imports, and platform-specific software.

Detection is reliable only when the file carries a recognized Unicode signature or the surrounding format declares its encoding. A byte sequence that is valid UTF-8 can still have been intended as a legacy encoding, and many legacy encodings share the same byte values for ASCII text. Ambiguous files need information from the producing application, file specification, or a known-good sample.

Replacement policies trade continuity for fidelity. Stopping on the first invalid or unrepresentable sequence protects against silent data loss. Replacing bad input can produce a usable file for recovery or migration, but each substitution permanently loses information unless the original bytes are kept.

Re-encoding should leave the character sequence unchanged unless line endings or invalid-data handling are deliberately altered. Always keep the source file until the target application opens the converted copy and critical punctuation, accented letters, symbols, and non-Latin text have been checked.

How to Use This Tool:

Identify the source encoding as confidently as possible before choosing the bytes that the destination application expects.

  1. Choose a Local text file no larger than 2 MB. Keep an untouched copy because a wrong source encoding or replacement policy can change text irreversibly.
  2. Set Source encoding. Auto detect accepts a UTF-8 or UTF-16 byte-order mark first, then accepts BOM-less input only when it is strictly valid UTF-8. Choose UTF-16 or Windows-1252 explicitly when the source is known.
  3. Choose the Target encoding required by the receiving application. UTF-8 is the broadest general-purpose choice; Windows-1252 is suitable only when the destination requires that legacy character set.
  4. Keep Unmappable text on Stop for fidelity. Use replacement only for a reviewed recovery workflow, then inspect every recorded substitution.
  5. Set the Byte-order mark and Line endings to match the destination. Preserve keeps a compatible signature only when the source had one and leaves existing line separators unchanged.
  6. Review the resolved source encoding, replacement counts, line-ending changes, and byte totals. Download the file and open it in the real destination before discarding the source.

Interpreting Results:

Resolved source encoding states the decoder actually used. When auto detection reports a BOM, confidence comes from an explicit byte signature. When it reports valid UTF-8, the bytes passed strict UTF-8 validation but could still be ambiguous if the producing system used a legacy encoding whose bytes happen to be valid UTF-8.

  • Decode replacements mean invalid source byte sequences were replaced with U+FFFD.
  • Encode replacements mean target encoding could not represent a character; Windows-1252 output uses a question mark in its place.
  • Line endings changed counts separators that were rewritten to LF or CRLF.
  • Input and output bytes can differ even when the character text is identical because encodings use different byte widths and signatures.

A zero-replacement result is necessary but not sufficient. The wrong explicit source encoding can decode every byte without an error and still produce the wrong characters. Verify recognizable words, punctuation, currency symbols, and a few non-ASCII characters in the destination application.

Technical Details:

Encoding conversion is a two-step mapping: source bytes are decoded into Unicode code points, then those code points are encoded as target bytes. Byte-order marks and line-ending normalization sit at the boundaries of that mapping rather than changing the meaning of ordinary characters.

Transformation Core:

Stage Transformation Failure or review condition
Resolve source Recognize UTF-8 EF BB BF, UTF-16LE FF FE, or UTF-16BE FE FF. Without a signature, auto mode accepts only strict UTF-8. BOM-less non-UTF-8 data is reported as ambiguous instead of guessed.
Decode Map UTF-8, UTF-16LE, UTF-16BE, or Windows-1252 bytes to Unicode code points. Invalid UTF sequences stop conversion or create U+FFFD events according to policy.
Normalize lines Preserve every separator, or rewrite CRLF, CR, and LF to the selected LF or CRLF sequence. Normalization changes file bytes and can affect exact comparisons or executable text files.
Encode Map Unicode code points to the selected target bytes. Windows-1252 cannot represent most scripts and symbols outside its single-byte map.
Apply signature Preserve a compatible source signature, add the selected Unicode signature, or remove it. Windows-1252 has no byte-order mark, so an add request is rejected.

Worked Byte Path:

A UTF-8 file containing EF BB BF 43 61 66 C3 A9 begins with a UTF-8 signature and decodes to “Café”. Converting to UTF-16 little-endian with a preserved signature produces FF FE 43 00 61 00 66 00 E9 00. The characters stay the same; only byte representation and signature change.

Encoding Map:

Encoding Unit width Coverage Signature behavior
UTF-8 1 to 4 bytes per code point Full Unicode scalar range Optional three-byte signature; no byte-order role.
UTF-16 little-endian 2 or 4 bytes per code point Full Unicode scalar range through surrogate pairs FF FE identifies little-endian order.
UTF-16 big-endian 2 or 4 bytes per code point Full Unicode scalar range through surrogate pairs FE FF identifies big-endian order.
Windows-1252 1 byte per character Western European repertoire only No signature.

Rule Core:

  • Input is limited to 2,097,152 bytes and output to 4,194,304 bytes.
  • A source BOM that conflicts with an explicit encoding causes an error rather than being ignored.
  • UTF-8 validation rejects overlong sequences, surrogate encodings, code points above U+10FFFF, bad continuation bytes, and truncated sequences.
  • UTF-16 validation checks complete code units and properly paired leading and trailing surrogates.
  • Windows-1252 bytes from 80 to 9F use the converter's fixed single-byte map; the five historically undefined positions become their corresponding C1 control code points.
  • At most 100 decode and encode replacements are recorded; conversion stops if more would be required.
  • The output filename adds the selected encoding while retaining the original extension when present.

Privacy Notes:

The selected file is decoded and re-encoded in the browser rather than uploaded for processing. Its contents can still appear in browser memory and in the downloaded copy. Use an approved device and storage location for secrets, personal data, or regulated records.

References: