Skip to content
Pixora

Fix Subtitle Encoding

Processed locally in your browser — nothing is uploaded.

Quick answer

Garbled subtitle characters — "é" where "é" should be, or black "�" boxes — are a text-encoding problem, not corruption. They appear when a legacy 8-bit file (Windows-1251, 1252, Shift-JIS and others) is read as UTF-8. This tool detects the real encoding, lets you pick the correct one, and re-saves clean UTF-8. It all happens in your browser; the file is never uploaded.

How to fix subtitle encoding

  1. Load the garbled file

    Drop the subtitle file that shows strange characters, or paste it. The tool reads the raw bytes and guesses the most likely original encoding.

  2. Pick the right encoding

    Preview the text under the detected encoding. If accented or non-Latin characters look right, keep it; if not, choose another (1250, 1251, 1252, 1253, Shift-JIS, GBK…) until the preview reads correctly.

  3. Save as clean UTF-8

    Export the re-decoded file as UTF-8. The characters now display correctly in any modern player or browser.

Why does mojibake happen?

Text on disk is just bytes; an encoding is the agreement about which byte means which character. For decades subtitles were saved in regional 8-bit encodings — Windows-1252 for Western European, 1251 for Cyrillic, 1250 for Central European, 1253 for Greek, Shift-JIS for Japanese, GBK for Chinese. In those encodings a single byte like 0xE9 means "é". Modern software instead assumes UTF-8, where "é" is stored as two bytes (0xC3 0xA9). When a player reads an old 1252 file as if it were UTF-8, that single 0xE9 byte is no longer a valid UTF-8 sequence — so you get "é", a stray character, or the "�" replacement box. That mangled output is called mojibake.

How do you read the clues?

The exact garbling hints at the source encoding, which helps you pick the right one quickly:

Reading mojibake back to its likely source.
What you seeLikely causeEncoding to try
é, è, ü for é, è, ü8-bit Western read as UTF-8Windows-1252 / ISO-8859-1
replacement boxesBytes invalid as UTF-8Try 1252, then the regional code
Latin letters where Cyrillic belongsCyrillic file misreadWindows-1251
Wrong accents in Polish / Czech / HungarianCentral European misreadWindows-1250
Scrambled GreekGreek file misreadWindows-1253
Garbled JapaneseJapanese file misreadShift-JIS
Garbled ChineseSimplified Chinese misreadGBK / GB18030

What does fixing it actually do?

The fix is a re-decode plus a re-encode. The tool reads the raw bytes, decodes them with the correct legacy encoding so each byte maps to the character its author intended, then re-encodes the text as UTF-8 and saves that. The output is a modern UTF-8 file that every current player and browser reads correctly — and you should keep it as UTF-8 from now on, since it is the universal default.

One more sign to watch for is a byte-order mark (BOM) — a few leading bytes some editors add to UTF-8 or UTF-16 files. A stray BOM can make the first cue number look odd or add an invisible character before the first line. Re-saving as clean UTF-8 normalises this too, so the file starts exactly where it should.

Is my file uploaded to fix the encoding?

No. The bytes are read and re-decoded in your browser using its built-in text decoders; the re-encoded UTF-8 file is built locally. Nothing is transmitted — verify it in DevTools → Network. This matters for private or unreleased captions, which never leave your device.

Once the text is clean UTF-8 you can safely convert the file to another format or open it in the subtitle editor without the garbling coming back. When it looks right everywhere, add the subtitles to your video.

Your files never leave your device

Processed locally in your browser — nothing is uploaded. You can verify it yourself: open your browser’s developer tools, watch the Network tab, and use the tool — no upload request is ever made.

Frequently asked questions

What does "é" instead of "é" mean?

It means a Western 8-bit file (usually Windows-1252) is being read as UTF-8. Re-decode it with the correct encoding and re-save as UTF-8 and the accented letters come back.

What are the "�" black boxes?

That is the Unicode replacement character, shown when a byte is not valid in the encoding the player assumed. It signals the file was decoded with the wrong encoding, not that it is corrupted.

Is my file actually damaged?

Almost never. Mojibake is a labelling problem: the bytes are intact but read with the wrong encoding. Decode with the right one and no data is lost.

How do I know which encoding to pick?

The tool detects a likely one, but preview the result. If the accented or non-Latin characters read correctly it is right; if not, try the encoding for the file’s language — 1251 for Cyrillic, 1250 for Central European, Shift-JIS for Japanese, and so on.

Why should I save as UTF-8?

UTF-8 can represent every language and is the default modern players and browsers expect, so a UTF-8 file displays correctly everywhere and will not garble again.

My Cyrillic subtitles show as random Latin letters. Which encoding?

Try Windows-1251, the standard Cyrillic code page. The preview should switch to readable Russian, Ukrainian or other Cyrillic text.

Can this fix Japanese or Chinese subtitles?

Yes. Choose Shift-JIS for garbled Japanese, or GBK/GB18030 for garbled Simplified Chinese, then export as UTF-8.

Will fixing the encoding change the timing or tags?

No. Only how the bytes are decoded into characters changes. Timestamps, cue numbers and any tags are untouched.