Subtitle Encoding Fixer — Repair Mojibake and Weird Characters

How It Works

Before and After

A French subtitle line saved correctly as UTF-8:

1
00:00:01,000 --> 00:00:03,000
"Bonjour, mon ami — ça va?" elle dit avec un sourire.

The same line after a typical encoding round-trip mistake (UTF-8 read as Windows-1252, then re-saved as UTF-8):

1
00:00:01,000 --> 00:00:03,000
"Bonjour, mon ami â€" ça va?" elle dit avec un sourire.

The em-dash (—) has become â€" and the ç has become ç. Selecting the correct source encoding from the dropdown — or enabling reverse mojibake if the file has already been double-encoded — restores the original text. Timestamps and cue numbers are never affected.

Mojibake Character Decoder

If your subtitles show literal sequences of two or three Latin characters where accented letters or smart quotes should be, the file is almost certainly UTF-8 being read as Windows-1252. The table below lists the most common mojibake patterns and what they should decode to.

Every pattern in this table has the same root cause: UTF-8 bytes being interpreted as Windows-1252. The fix is the same in all cases. If the encoding picker is set to UTF-8 and you see these sequences, click Try reverse mojibake fix. If the picker is on Windows-1252, switching to UTF-8 (or the correct source encoding for your script) usually resolves them.

What Is Mojibake and How Does It Happen?

Subtitle files break when one application saves them in UTF-8 and another opens them with a legacy single-byte encoding like Windows-1252 — or the reverse. That mismatch produces mojibake: strings of replacement symbols, accented letters turned into pairs of Latin characters, or diamond question marks where real letters should be.

Three patterns cause most subtitle corruption:

• Encoding mismatch. The file was written in one encoding and is being read as another. Russian subtitles saved as Windows-1251 but opened as UTF-8 produce one type of garbled output; UTF-8 French subtitles opened as Windows-1252 produce another.
• Double-encoding. UTF-8 bytes were misread as Windows-1252, then re-saved as UTF-8. The result is mojibake layered on top of itself — literal sequences like é appearing in the text instead of é. The reverse mojibake toggle is built for this exact case.
• BOM confusion. Some older Windows applications expect a UTF-8 byte-order mark to recognise multilingual content; others mishandle it. The BOM checkbox lets you control whether the exported file includes one.

How the Tool Detects Encoding

On upload, the Subtitle Encoding Fixer auto-detects encoding in this order:

• UTF-8 BOM (bytes EF BB BF) → labelled "UTF-8 (BOM)"
• UTF-16LE BOM (bytes FF FE) → decoded and transcoded to UTF-8 for a consistent pipeline
• UTF-16BE BOM (bytes FE FF) → decoded and transcoded to UTF-8
• Strict UTF-8 validation→ if all bytes form valid UTF-8 sequences, labelled "UTF-8"
• Fallback → Windows-1252, a sensible default for Western legacy text

Legacy non-BOM encodings like Windows-1251 (Cyrillic), Shift_JIS (Japanese), or Big5 (Traditional Chinese) cannot be unambiguously detected from bytes alone. If auto-detect picks Windows-1252 but your file is actually Cyrillic or East Asian, pick the right encoding from the dropdown and watch the After preview update in real time.

Choosing the Right Encoding for Your Language

Auto-detect handles BOM-marked files and valid UTF-8 files automatically. For legacy files without BOMs, use this guide to pick the most likely encoding from the dropdown:

The "Try first" column reflects the encoding that historically shipped with subtitle files for that language before UTF-8 became universal around 2010. Files produced after about 2015 are most often UTF-8 regardless of language.

Step-by-Step Recipes for Common Scenarios

Below are explicit walkthroughs for the five most common subtitle encoding problems.

When to Use the Subtitle Encoding Fixer

• After downloading a subtitle file that displays gibberish — accented characters turned into question marks, or sequences like ’ or é.
• After converting subtitles between platforms — some older video editors export legacy encodings while modern players expect UTF-8.
• When subtitles play correctly in one app but break in another — usually an encoding mismatch rather than a corruption.
• Before uploading subtitles to YouTube, Vimeo, or other platforms that require valid UTF-8.
• When passing subtitles between Windows, macOS, and Linux systems that have different default encodings.
• After AI auto-transcription tools occasionally produce files with mixed or unexpected encodings.

Who Uses This Tool

Video editors and captioners working with subtitle files from international sources. Translators bridging files between language editors that default to different encodings. YouTubers, Vimeo creators, and broadcasters who need clean UTF-8 deliveries. Anyone who downloaded a subtitle pack from a non-English release and saw boxes or random symbols instead of real letters.

Why Use This Subtitle Encoding Fixer

• Auto-detects UTF-8 (with or without BOM), UTF-16LE, and UTF-16BE on load.
• Ten manual encoding options covering Western, Cyrillic, Central European, Latin, Japanese, Chinese, and Korean scripts.
• Reverse mojibake toggle for the common double-encoding case.
• Optional UTF-8 BOM on export for older Windows tools.
• Always exports valid UTF-8, regardless of input encoding.
• Runs entirely in your browser — no upload, no account, no install.
• Preserves all timestamps, cue numbers, and formatting tags untouched — only the byte-to-character mapping changes.

Glossary of Subtitle Encoding Terms

Key terminology you will see in encoding documentation, error messages, and across subtitle tools.

Character encoding

A mapping between binary byte sequences and the characters they represent. The same bytes can mean different characters in different encodings, which is why subtitle files sometimes display correctly in one tool and incorrectly in another.

Code point

A unique number assigned to each character in the Unicode standard. The letter "A" is code point U+0041; the symbol "♥" is U+2665; the smart apostrophe ' is U+2019.

UTF-8

The dominant character encoding for modern text files. It uses 1 byte for ASCII characters and 2 to 4 bytes for everything else. UTF-8 is the WHATWG standard for the web and the default for modern subtitle workflows.

UTF-16

A two-byte-per-character encoding (with surrogate pairs for higher code points). UTF-16 files always start with a byte-order mark: FF FE for little-endian, FE FF for big-endian.

BOM (Byte Order Mark)

A few bytes at the start of a file that signal the encoding to the reader. UTF-8 BOM is EF BB BF; UTF-16LE BOM is FF FE; UTF-16BE BOM is FE FF. BOMs are optional for UTF-8 but mandatory for UTF-16.

Windows-1252

A single-byte encoding designed for Western European languages. Often confused with ISO-8859-1 (Latin-1) but slightly different. It's the most common source of mojibake when its bytes are misread as UTF-8.

ANSI

A legacy Windows term that refers to whichever single-byte encoding is active on a given Windows system — usually Windows-1252 in English/Western European installations, Windows-1251 on Russian Windows, etc. ANSI is NOT a specific encoding; it's a system setting.

Mojibake

Garbled text that appears when bytes are interpreted with the wrong character encoding. The name comes from Japanese 文字化け (moji-bake), literally "character transformation."

Replacement character

A symbol (typically U+FFFD, shown as a black diamond with a question mark, or as an empty box) used to represent bytes that don't form a valid character in the chosen encoding.

Code page

Another name (chiefly Windows) for a character encoding. Windows-1252 is also called "Code Page 1252" or "CP1252."

Frequently Asked Questions

Related Tools

Other free subtitle tools you can use alongside the Encoding Fixer:

• Subtitle Tag Stripper
• Subtitle Find & Replace
• SRT to VTT Converter
• VTT to SRT Converter
• Subtitle Overlap Fixer
• Subtitle Time Shifter