Encoding conversion does not “relabel” an already-decoded string; it starts from the file's binary bytes. The implementation first looks for a UTF-8 or UTF-16 BOM and tries strict UTF-8; when that fails it tries GBK, Big5 and Shift_JIS, scores the candidates for readability and recommends one, which the user confirms against a preview before it is re-encoded as UTF-8.

1. 01Choose a text file of 50 MB or less.
2. 02If several encoding candidates appear, pick the right source encoding by comparing the previews.
3. 03Choose whether to add a UTF-8 BOM, and decide between keeping the line endings, normalising to CRLF or normalising to LF.
4. 04Convert and download the new -utf8 file.

A GBK CSV → strict GBK decoding → Unicode text → UTF-8 bytes. Choosing CRLF normalises every CRLF/CR/LF to \r\n; choosing LF normalises CRLF/CR to \n.

• The file limit is 50 MB.
• Automatic encoding detection is a heuristic; a non-UTF-8 candidate should be confirmed by a human against the preview.
• The lenient UTF-8 fallback shows damaged bytes as �, which means the information can no longer be recovered losslessly.
• The output encoding is always UTF-8; no new GBK, Big5 or Shift_JIS file is produced.
• Binary files do not suit this tool — a wrong decode destroys the bytes.

The source bytes, the decoded text and the output are all handled locally in the browser and are never uploaded.