UTF-8 Converter
Convert subtitle encoding to UTF-8 for universal compatibility
Drop your subtitle file here
or click to browse (multiple files supported)
Supported: SRT, VTT, ASS, SSA, SBV, SUB, SMI, SAMI, LRC, TTML, ITT, DFXP
About the UTF-8 Encoding Converter
Subtitle files downloaded from older sites or ripped with legacy tools are often saved in a non-Unicode encoding (Windows-1252, Windows-1251, GBK, Shift-JIS…). Play them in a player expecting UTF-8 and you get garbled text, question marks, or mojibake instead of readable subtitles. This tool detects the real encoding and re-saves your file as clean UTF-8, same format, same timing, just fixed text.
What Causes Garbled Subtitles?
Every text file is just bytes until something decides how to turn those bytes into characters (that decision is the encoding. A file saved as Windows-1251 (Cyrillic) or GBK (Chinese) looks perfect in the tool that made it, but opens as garbage in a player or editor that assumes UTF-8. The fix isn't re-typing the file) it's re-decoding the exact same bytes with the correct encoding, then re-saving as UTF-8, which every modern player and OS understands.
Common Causes of Encoding Issues
- Legacy subtitle sites that still export Windows-1252 or region-specific code pages instead of UTF-8.
- Non-Latin languages (Russian, Chinese, Japanese, Korean, Thai, Arabic, Greek, Hebrew) saved in a legacy single- or double-byte encoding rather than Unicode.
- Old ripping/OCR tools that default to the system's regional code page instead of UTF-8.
- Copy-pasting between editors that silently re-save in a different default encoding than the one you started with.
When You Need This
Fix Mojibake
Your subtitles show question marks, boxes, or nonsense characters instead of accented letters or non-Latin scripts, the file just needs re-decoding with its real encoding.
Legacy Rips and Old Downloads
Subtitles downloaded years ago or ripped with an older tool often predate widespread UTF-8 adoption and need converting before modern players will render them correctly.
Editor and Player Compatibility
Standardizing every subtitle file to UTF-8 avoids repeat encoding guesswork the next time you open it in a different editor, player, or OS.
Frequently Asked Questions
Why do my subtitles show question marks or garbled characters?
This almost always means the file was saved in a non-UTF-8 encoding (like Windows-1252, GBK, or Shift-JIS) but is being opened by something that assumes UTF-8. The text itself is fine, it just needs re-decoding with the correct original encoding.
How do I know which encoding my subtitle file uses?
Upload it here: the encoding is auto-detected and shown with a confidence score. If the detected encoding still looks wrong in the preview, try the encodings matching your subtitle's language from the override dropdown.
Will this change my subtitle timing or formatting?
No. Only the byte encoding changes: cue timing, text content, and the subtitle format (SRT stays SRT, VTT stays VTT, ASS stays ASS) are all preserved exactly.
Can I convert to an encoding other than UTF-8?
Not with this tool: it only converts TO UTF-8, since that's what virtually every modern player, browser, and OS expects. UTF-8 can represent every language, so there's rarely a reason to go the other way.
Is my file uploaded to a server?
No. Detection and conversion both run locally in your browser, your subtitle file never leaves your device.
Encoding Tips
If the detected encoding looks wrong, check the dropdown for encodings matching your subtitle's original language: Cyrillic, CJK, and Arabic/Hebrew code pages are the most commonly misdetected.
A high confidence score usually means the auto-detection got it right the first time; a low score is a signal to eyeball the preview before downloading.
Keep your original file until you've confirmed the converted preview looks correct, re-decoding is easy to redo, but the original bytes are your only source of truth.
This tool changes only the byte encoding, never the subtitle format or timing, a converted SRT stays an SRT with identical cues.
If your subtitles still look wrong after picking every plausible encoding, the original file itself may already be corrupted rather than mis-encoded.
