Remove the BOM from Subtitles
Or paste subtitle text
Options
A BOM is three bytes at the very start of the file that spell out which encoding it is in. It is invisible in every editor and player, it takes up no room on screen, and nothing in the subtitles changes when it is added or removed. Two kinds of tool care about it: Windows programs that write subtitles, which put one in by default, and strict parsers in build pipelines, which reject a file that starts with one. This page opens the box in the state its title names, so you can flip it if your file turns out to be the other way round. A file in UTF-16 always carries a BOM, because that is how a reader knows which of the two byte orders it is looking at — asking to remove one there leaves it in place.
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.
The byte order mark is one character, U+FEFF, sitting in front of everything else in a file. Plenty of tools write it and plenty of tools do not expect it, and the ones that do not show it as a short block of symbols glued to the start of the first cue. This page takes it off and leaves everything else exactly as it found it.
Removing it matters most where the file stops being something a person reads and starts being something a program parses: subtitle build pipelines, scripts that read the first line of a file, and formats whose specification says the opening bytes are the first character of the first cue. It matters too when files are concatenated, because a mark in the middle of a joined file is a character in the middle of a cue. And it matters for delivery: if the spec you are delivering to says UTF-8 without a mark, a mark is a difference the checker will find.
What the page will not do is decide anything else for you. Cue numbers, timecodes, cue text and line endings all come back as they went in, including CRLF, and a file that had no mark comes back byte for byte rather than being rewritten into something equivalent. Removing a mark is not the same as changing a file's character encoding, and the two are often confused: this page changes the first character of the file and nothing about how the rest of it is encoded.
There is one case where the title of this page and what actually happens come apart, and it is worth knowing before you run it. A UTF-16 file needs its mark: without one there is no way to tell the two byte orders apart, so a UTF-16 file written without a mark cannot be read back. Send one through this page and the downloaded file will still carry a mark, because the alternative would be a file nobody can open. If your file is UTF-16 and the mark has to go, what you want is a different encoding rather than the same one without the mark, and the page that converts encodings is linked below.
The mark is removed from the file you download, so the two panes can look identical here — a zero-width character is exactly what an invisible character looks like. Check the result in your editor's encoding indicator or in a hex viewer: a file with no mark starts with the first byte of its first cue. All twelve formats this site handles are accepted, from SRT to a plain text transcript, and nothing is uploaded: the file is read, changed and written inside your browser.
Examples
A marked file, with the mark taken off
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 input starts with U+FEFF and the output does not: the two files differ by exactly that one character, which is the whole of the operation. Files in this state usually came out of a Windows subtitle program, and the reason people want the mark gone is a build step or a strict parser that looks at the opening bytes instead of at the cues.
A Windows file, mark removed and carriage returns kept
Input
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Output
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Only the mark goes. Every carriage return is the file's own and this page has no view on them — somebody who wants both changed wants the line ending page, and keeping the two apart is what makes each of them safe to run on a file you have not opened. The expected text still holds its CRLF exactly as the input did.
A file with no mark, returned byte for byte
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.
There was nothing to remove, so the file comes back unchanged — including the absence of a mark. This is the case that catches an implementation which writes a mark first and strips it afterwards, or which normalises the file on the way through: the honest reading of "there was nothing to do" is the input itself, byte for byte, and not a tidy version of it.
Frequently asked questions
How do I tell whether my subtitle file has a byte order mark?
Open it in an editor that shows the file encoding, and a UTF-8 file with a mark is usually labelled UTF-8 with BOM or UTF-8 BOM rather than plain UTF-8. Failing that, look at the first bytes in a hex viewer: a file that begins EF BB BF carries one and one that begins with the first character of the cue does not. The block of symbols at the start of the first line is the same thing seen by a program that read the mark as three ordinary characters.
Why does the mark stay on a UTF-16 subtitle file after removing it?
Because a UTF-16 file needs one. UTF-16 stores every character as two bytes and the two byte orders look alike from the outside, so the mark is what tells a reader which order it is in — a UTF-16 file without a mark cannot be read back, by this site or by anything else. The page you are on keeps it for that reason. To get a file that has no mark at all, change its encoding to UTF-8 or Windows-1252 instead, where the mark is optional.
Does this page damage a subtitle file that never had a mark?
No. The output of that case is the input, byte for byte, and nothing is reported for it. Running the page on a file whose state you are unsure of is safe by construction for the same reason: with no mark to remove there is nothing to write, and with one there is the smallest possible change. A run that found nothing to do is not a run that did something.
Can a subtitle file have more than one byte order mark?
Yes, and it happens whenever a tool adds a mark without checking for one first — the second mark makes a file that looks completely normal in an editor while differing from a normal file in its opening bytes. This page removes all of them rather than one, so a doubly-marked file is cleaned in a single pass and running the page again changes nothing further.
Does removing a mark change the encoding of my subtitle file?
Not in the sense people usually mean. The text of the file is still the same characters and the rest of it is still encoded the same way; what changes is that a reader no longer has the file's opening bytes telling it the encoding. A UTF-8 file without a mark is ordinary UTF-8, which is what most tools assume anyway. Changing the encoding itself is a separate page, linked from here.
Will the mark come back when I download the subtitle file?
No. The download is the point at which the file is written, and a run of this page writes it without a mark, so what you get is what the two panes describe. The encoding a file is written in is preserved from how it was read, with one exception: a file that arrives as UTF-16 is written back as UTF-16 and keeps its mark, because that mark is structural rather than decorative.