Fix Subtitle Encoding
Or paste subtitle text
Options
This one changes how the file is read, not what is written. Normally the encoding is worked out from the first bytes: a byte order mark if there is one, UTF-8 if the file is valid UTF-8, and Windows-1252 otherwise. That gets Western European files right and gets everything else wrong, so a Japanese, Chinese, Korean or Cyrillic file arrives as a screen of accented nonsense. Name the encoding here and the guessing is skipped. Detect automatically is the default and does nothing at all, which is why it is safe to leave alone. Note that the result is written back as UTF-8: browsers can only produce a handful of encodings, and none of the ones in this list is among them. That is the point of the page — the text comes out correct and in a form every tool can read.
Which frame rate the timings are counted in. On the format pages this is what MicroDVD needs, because it stores timing as frame numbers. On the frame rate pages it is the rate the file was timed against — the version the subtitles were made for — and the page's second box takes the rate of the video you are going to use them with. 23.976, 24, 25, 29.97, 30, 50, 59.94 and 60 are the common ones. Getting it wrong shifts the whole timeline, and on the frame rate pages it shifts it by a ratio rather than by a fixed amount.
Some subtitle files arrive as a screenful of symbols that belong to no language. The file is not damaged and the text is not gone: the program reading it applied the wrong rule to the bytes, and the characters that came out are what those bytes mean under a different rule. This page lets you say which rule to use, and it applies it before anything else happens to the file.
The reason it needs to be you is that the bytes usually do not say. A program opening a subtitle file guesses: a mark at the start settles it, valid UTF-8 settles it, and otherwise it falls back on something — commonly the local codepage of whoever is running the tool rather than whoever wrote the file. Japanese, Korean and Chinese subtitle files are the cases where the guess goes wrong most often, because those encodings were the default on the machines that produced them and their bytes are not valid UTF-8. Anyone who knows which program wrote the file knows more than the guesser does, and this page is where that knowledge goes.
Automatic is the default and means the guess runs exactly as it always has, so opening this page on a file that already reads correctly changes nothing. Pick a specific encoding and the file is read that way instead, before the subtitle is parsed — which is why this page has no separate "apply" step in the usual sense, and why a file that reads correctly can come out of it with the same cues, timecodes and line endings and a completely different set of characters. What you are choosing is the reading, not an edit.
Two things about the outcome are worth knowing in advance, and the page reports both. The first is that a wrong choice looks like a wrong choice: the symbols change into different symbols rather than into text, and nothing is damaged by trying. The second is a real limitation of the browser: the encodings here that a browser can read it cannot all write. A file repaired as Shift-JIS, GBK, Big5 or EUC-KR is therefore written back out as UTF-8, which reads correctly everywhere and is what modern tools expect — but it is not the encoding you named, so if a downstream system insists on the original one, convert the file with a desktop tool after repairing it here.
One entry in the list deserves a word of its own. ISO-8859-1 and automatic reach the same code table in a browser, because the standard says that label means the Western European one. It is still worth having, because it does something automatic cannot: it overrules the guess. A Western European file whose bytes happen to form a valid UTF-8 sequence is read as UTF-8 automatically, and the characters you see are then not the ones in the file; naming ISO-8859-1 forces the Western reading. All twelve subtitle formats are accepted, and nothing is uploaded — the file is read and written inside your browser.
Examples
Automatic detection on a file that already reads correctly
Input
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
Output
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
The default setting, and the only one that asks for nothing: with automatic selected no encoding is named, so the file is read exactly as it was before this page existed. That makes it safe to open on a file you are unsure about — if nothing was wrong, nothing happens — and it is the setting to fall back on when a specific choice made things worse.
The same file read as Shift-JIS
Input
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Output
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
The same file read two ways. What the pane holds once the bytes have been read as Shift-JIS is the Japanese they were saying all along; read as Western text, those same bytes are a line of unrelated accented letters, and that is the state that sends people looking for this page. Both panes of this example show the readable version, because the re-reading happens before the subtitle is parsed — there is no step of the page at which the wrong characters are on screen and the right ones are not.
A Western file that automatic detection reads as UTF-8
Input
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Output
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
The hard case, and the only one where automatic and a named encoding disagree in a browser. The file's bytes happen to form a valid UTF-8 sequence, so the guess is UTF-8 and the characters handed over are not the ones in the file. Naming ISO-8859-1 forces the Western European reading instead. It is the same code table either way, which is the part that is easy to get wrong from older documentation: what the choice does is overrule the guess.
Frequently asked questions
Why does my subtitle file show strange characters instead of the right text?
Because the bytes were read under the wrong rule. The file holds Japanese, Korean or Cyrillic text stored in the encoding the program that wrote it used, and the program reading it assumed something else — very often the local codepage of the machine rather than the file. Nothing is damaged: the same bytes under the right rule give the right text, which is what naming an encoding on this page does.
How do I find out which encoding a subtitle file is really in?
Usually from what produced it. A Japanese file from a Japanese Windows tool is most likely Shift-JIS, a Chinese one from the mainland is GBK and from Taiwan is Big5, Korean is EUC-KR, and Cyrillic is Windows-1251 most of the time. Failing that, try them: the wrong choice gives symbols and the right one gives text, so a file can be identified in a few seconds without knowing anything about it.
What happens if I choose the wrong encoding for my subtitle file?
The characters change into a different set of wrong characters, and nothing else happens — the original file on your disk is untouched, and nothing is uploaded or saved anywhere. Trying again is free. The one outcome worth watching for is a file that reads correctly but shows a suspiciously long line of symbols at the top, which means it also carries a mark that the chosen encoding read as characters.
Why is my repaired subtitle file written as UTF-8 when I picked Shift-JIS?
Because the browser can read that encoding but cannot write it. A file read as Shift-JIS, GBK, Big5 or EUC-KR is written back out as UTF-8, which holds every character it contains and is what nearly all current software expects. The subtitle text is exactly what you see in the pane; only the container changed. If a downstream system requires the original encoding, convert the repaired file with a desktop tool.
Does fixing the encoding modify the text of my subtitles?
No. The bytes of your file are not altered, and no character is added, removed or replaced; what changes is the rule used to turn those bytes into text, and everything after that step works with the correct text. Cue numbers, timecodes and line endings are the file's own, exactly as they are on every other operation page here.
Is automatic encoding detection good enough, or should I always set it?
Automatic is right for the large majority of files, and it is the default because a file that reads correctly should not need you to say anything. Set the encoding when the text is visibly wrong, when you know what produced the file, or when a batch came from one source and should be read one way. One case where it will not help: a file in an encoding the browser has no decoder for at all, which will stay wrong whichever option you pick.