Encoding Converter

From ToolzPedia, the free tools encyclopedia
This is one of several utilities. For the full list of utilities, see All tools.

The Encoding Converter takes a subtitle or text file saved in any character encoding and rewrites it in the one you need, almost always UTF-8. Text files do not store letters directly; they store numbers (bytes), and a character encoding is the lookup table that maps those bytes back to letters. When a file is created with one table and opened with a different one, accented letters, Cyrillic, Greek, Arabic or East-Asian characters turn into garbage like é or £. That garble has a name, mojibake, and fixing it is exactly what this tool is for.

Subtitles are where this problem bites hardest. A huge number of SRT, VTT and ASS files floating around the web were saved years ago in legacy regional encodings such as Windows-1252 (Western Europe), Windows-1251 (Cyrillic) or Shift_JIS (Japanese). Open one of those in a modern editor or load it into a video player that expects UTF-8, and every special character breaks. Converting the file to UTF-8 once, cleanly, makes it readable everywhere and safe to edit, translate, compare or merge.

Everything happens inside your browser using the built-in TextDecoder and TextEncoder APIs. Your files are never uploaded, which matters when you are working on an unreleased film, a client's script or any material under embargo. You can convert a whole batch at once and download them together as a ZIP.

Use the tool edit

🔡
Drop text or subtitle files here or click to upload

SRT · VTT · ASS/SSA · SUB · TXT and more · Processed in your browser · You can add several at once

How to use Encoding Converter edit

Follow these steps to use the tool:

  1. Add your files

    Drop one or more subtitle or text files. Everything stays on your device.

  2. Check the detected encoding

    Each file is auto-detected. Override the source encoding manually if a file still looks garbled.

  3. Pick the target

    Choose UTF-8 (the safe default), UTF-8 with BOM, or UTF-16, and optionally normalise line endings.

  4. Convert & download

    Download a single converted file, or a ZIP when you convert several at once.

Frequently asked questions edit

Unicode (UTF-8, UTF-16 LE and BE), Western (Windows-1252, ISO-8859-1 and -15, Mac Roman), Central and Eastern European (Windows-1250, ISO-8859-2, Windows-1251, ISO-8859-5, KOI8-R), Greek, Turkish, Arabic and Hebrew code pages, and the major East-Asian encodings Shift_JIS, EUC-JP, GB18030, Big5 and EUC-KR. These are the standard labels supported by the browser's decoder.
UTF-8 (the recommended modern default), UTF-8 with a byte-order mark, and UTF-16 LE with a BOM. UTF-8 is the universal standard and the right choice for virtually every editor, player and web use.
The page and conversion logic run in your browser, so once the page has loaded a single file converts without a connection. Converting several files into a ZIP loads a small compression library, which needs a connection the first time.
No. The tool only changes how characters are stored as bytes. Timestamps, cue numbers, positioning tags and styling in SRT, VTT or ASS files are plain text and pass through unchanged.
Files up to 25MB each are accepted, which is far larger than any normal subtitle or text file. Everything is processed in memory on your device, with no server-side limit.
Mojibake appears when a file saved in one encoding is read as another. For example, UTF-8 bytes for "é" read as Windows-1252 show up as "é". Decoding the file with its true original encoding and re-saving as UTF-8 repairs it permanently.

Use cases edit

Fixing garbled subtitles

A downloaded SRT shows "é" instead of "é". Pick the right source encoding, confirm the preview looks correct, and export clean UTF-8.

Preparing files for translation

Translation and subtitling tools expect UTF-8. Convert source files first so accented characters and non-Latin scripts survive the round trip.

Standardising a mixed batch

A folder of subtitles from different sources in different encodings can be normalised to UTF-8 in one pass and downloaded as a ZIP.

Cross-platform line endings

A file authored on Windows (CRLF) misbehaves in a Unix tool. Convert the line endings to LF while you are re-encoding.

Cleaning legacy text archives

Old TXT, CSV or notes saved in a regional codepage become universally readable once converted to UTF-8.

How it works edit

When you add a file, the tool reads its raw bytes (not text) into memory. It first looks for a byte-order mark, a short invisible signature at the very start of some files that explicitly declares UTF-8, UTF-16 LE or UTF-16 BE. If a BOM is present, the encoding is known with certainty.

If there is no BOM, the tool attempts a strict UTF-8 decode. Valid UTF-8 has a very specific byte structure, so if the decode succeeds without error the file is almost certainly UTF-8. If strict decoding fails, the tool falls back to Windows-1252, the most common legacy encoding for European text, and shows you the result so you can judge it. You can override the source encoding at any time from a list of Unicode, Western, Central and Eastern European, Greek, Turkish, Arabic, Hebrew, and East-Asian encodings, with a live preview that updates instantly.

Output is built byte by byte. For UTF-8 the tool uses the standard encoder; for UTF-8 with BOM it prepends the three-byte marker; for UTF-16 LE it writes the BOM and then two bytes per character. If you asked to normalise line endings, it rewrites every line break to LF or CRLF before encoding. The result is handed to you as a download, so the bytes on disk are exactly what you chose.

Tips and best practices edit

  • Watch the preview. The fastest way to find the right source encoding for a garbled file is to change the source dropdown until the preview reads correctly, then convert.
  • UTF-8 without a BOM is the right choice for almost everything today, web, modern players and editors all expect it. Only add a BOM if a specific older program demands it.
  • If accented characters look fine but you still have problems, the issue may be line endings rather than encoding, try switching those to LF or CRLF.
  • Convert a whole folder at once by selecting multiple files; the tool bundles the results into a single ZIP.
  • The tool treats input purely as text, so subtitle timing lines and tags are preserved exactly, only the byte encoding changes.

Common mistakes edit

Guessing the source instead of previewing

Legacy encodings overlap, so a wrong guess can look almost right. Always confirm with the live preview before converting, especially for Cyrillic, Greek and Turkish text.

Adding a BOM when it is not needed

A UTF-8 BOM can confuse some parsers, shell scripts and older players, making a stray character appear at the start of the file. Leave the BOM off unless something specifically requires it.

Assuming the file is UTF-8 because it mostly looks fine

Plain English text is identical in UTF-8 and most legacy encodings, so a file can look correct until the first accented character. Convert proactively if the file came from an unknown source.

Double-converting

Converting an already-UTF-8 file as if it were Windows-1252 will corrupt it. If the preview under auto-detect already looks perfect, the file is likely fine, convert only if you need a BOM or a line-ending change.

Comparison edit

How browser-based encoding conversion compares to common alternatives:

AspectToolzPedia (browser)Text editor "save as"Command line (iconv)
PrivacyFile never leaves your deviceLocalLocal
Auto-detectionBOM + UTF-8 probe + fallbackVaries, often manualNone, you must know the source
Batch conversionMany files to one ZIPOne file at a timeYes, with scripting
Live previewYes, before you commitOnly after openingNo
Ease of useNo install, no commandsEasy but per-filePowerful but technical

Other free utilities available on ToolzPedia:

See also edit