Skip to main content
SubtitleMatrix

Convert Subtitle Encoding

Text and stylingFix encoding and BOM
Or paste subtitle text

Options

This changes the bytes, not the subtitles. Every character in the file is written in the encoding you pick, so a player or a script that insists on one encoding gets a file it can read. UTF-8 is the one everything modern expects and the one this site writes everywhere else. UTF-8 with a BOM is the same bytes with the three-byte mark in front. UTF-16 LE is what Windows programs call Unicode and is roughly twice the size. Windows-1252 is the older Western European encoding, one byte per character, and it is the one to be careful with: it has no room for Chinese, Japanese, Korean, Cyrillic, Greek or emoji, so each character it cannot write comes out as a question mark and is counted in the report above. Nothing else about the file changes.

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.

A file's character encoding is the rule that turns its text into bytes, and it is the one property of a subtitle file that cannot be seen by looking at it. Notepad, a browser, a broadcast server and a television all have to be told or guess, and when they guess differently the text arrives as symbols that belong to no language. This page writes a file out under an encoding you name, so that the reading end has nothing to guess.

The default is to keep whatever the file arrived in, which is what you want most of the time: an operation like shifting a subtitle in time has no business rewriting the encoding, and a file that was UTF-16LE when it came in is still UTF-16LE when it goes out. Change this setting only when something in front of you names an encoding — a delivery specification, a tool that refuses a file, a player showing the wrong characters — or when you are standardising a folder of files that came from different places.

The four choices on the panel are the ones that come up. UTF-8 is what the web and most modern tools use, and what every conversion page on this site writes by default. UTF-8 with a mark is the same bytes with three extra ones in front, for the Windows programs that look at the opening bytes to decide. UTF-16LE is what Windows subtitle tools call Unicode, and it stores every character as two bytes, so the file comes out roughly twice the size. Windows-1252 is the older Western European encoding, still written by plenty of European broadcast tools, and it can hold the accents of Western European languages and nothing else.

That last point is a loss, and it is the reason this page reports one before you commit. Save Japanese, Chinese, Cyrillic or Greek subtitles as Windows-1252 and the characters that have no byte in that encoding are written as question marks — the file is not broken, the wrong characters are gone. The report above the workspace counts them and says how many, and the count comes from the same code table the encoder writes with, so the number you read is the number of question marks you will get. If the count is not zero, choose a different target.

The two panes on this page can look identical, and that is expected rather than a fault: an encoding is a property of the bytes, and the panes hold the characters. The change happens at the moment the file is written, which is when you download it. The row for each file says which encoding it was read as, and adds a second label naming the encoding it will be written as when the two differ. Nothing is uploaded, and the work is done in your browser.

Examples

An English subtitle file written as UTF-8

Input

1
00:00:01,000 --> 00:00:02,000
The room is dark.

Output

1
00:00:01,000 --> 00:00:02,000
The room is dark.

The default, and the encoding every other page of this site writes. The output equals the input because UTF-8 is what the file already was. What this case pins is the negative: choosing an encoding does not normalise anything else about the file, so a cue does not lose its line endings, gain a mark or change its timecode because you visited this page.

The same file written as UTF-16LE

Input

1
00:00:01,000 --> 00:00:02,000
The room is dark.

Output

1
00:00:01,000 --> 00:00:02,000
The room is dark.

Windows subtitle programs call this Unicode, and it is the encoding that makes the largest visible difference to the file: every character becomes two bytes, a mark goes in front, and the result is roughly twice the size. None of that is visible in these panes, because they hold characters — the file's size in your file manager and its encoding in your editor are where the difference shows.

Japanese subtitles written as Windows-1252

Input

1
00:00:01,000 --> 00:00:02,000
こんにちは

Output

1
00:00:01,000 --> 00:00:02,000
こんにちは

Five kana and an encoding with no room for any of them, so the loss report for this run counts five characters that become question marks. The panes still show the kana, because the substitution happens when the file is written rather than when it is read. That split is deliberate: you get to see what the file says and, in the report, what you would be giving up by writing it this way.

Frequently asked questions

What is the difference between a subtitle file's encoding and its format?

The format is how the file organises cue numbers, timecodes and text — SRT, WebVTT, ASS and so on — and it is something you can read. The encoding is how those characters are turned into bytes, and it is invisible: the same SRT file can be stored as UTF-8, UTF-16 or Windows-1252 and look identical in every editor. This page changes the second and leaves the first alone; the conversion pages change the first.

What happens to characters the target encoding cannot represent?

They are written as question marks, and the page tells you how many before you download. Windows-1252 covers Western European letters and has no byte for Japanese, Chinese, Korean, Cyrillic, Greek or emoji, so those characters cannot survive it in any form — there is no error and no substitution that keeps the meaning. The count in the loss report is the number of question marks in the file you would get, computed from the same table the writer uses.

Why do the two panes look the same when I convert a subtitle file's encoding?

Because the panes hold characters and the choice is about bytes. Text is text; whether each character takes one byte, two bytes or three is decided when the file is written, at download time. The row in the queue names the encoding each file was read as and adds a second label when the encoding it will be written as differs, and your own editor will report the encoding of the file you saved.

Which encoding should I pick for a subtitle file I am delivering?

UTF-8 unless something in the specification says otherwise, and the specification usually does say. Windows-1252 is common in European broadcast deliveries and is safe for Western European text only; UTF-16LE is what a Windows-only authoring tool may require. If the file was already in a suitable encoding, the default keeps it, which is the safest answer of all when nothing has gone wrong.

Does choosing UTF-16 make my subtitle file twice as big?

Yes, near enough. Every character is stored as two bytes, so an English subtitle file of 20 KB becomes about 40 KB, and a general-purpose compression step afterwards removes much of that difference. The mark in front adds two more bytes. Size is the trade for the property that made UTF-16 common on Windows: every character is the same width, which old software found easier to handle.

Why is there no UTF-16 big endian option in the encoding list?

Because nobody chooses it, and files that are already in it are handled anyway. A file that arrives as UTF-16 big endian is written back as UTF-16 big endian under the default setting, since keeping the input encoding is what the page does when you do not name one. The list holds the four targets people actually ask for; the underlying writer covers big-endian so that keeping a file as it was never silently changes it.

Related tools