Add a BOM to 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.
A byte order mark is one character — U+FEFF — sitting in front of everything else in the file. In UTF-8 it is three bytes, EF BB BF, and it is the first thing a reader sees. Nothing in this page's output looks different: the same cues, the same timecodes, the same line endings, and a mark in front of the first one.
Why anyone wants it there is that the mark is how a file says "I am UTF-8" without saying it. A program that opens a subtitle file has to guess which encoding it is in, and a great many of them — older Windows players, disc authoring tools, scripts that read the first line — decide by looking at the first bytes rather than by trying to parse the whole file. Give them the mark and an accented name, a curly quotation mark or a Greek letter comes out as itself. Leave it off and the same file may be read as the system's local codepage, where those characters turn into something else entirely.
The other direction is the one people usually meet first: a file that has a mark, opened by a tool that does not expect one. That tool reads the three bytes as three characters and shows them at the start of the first line, which is where the little block of symbols at the top of someone's subtitle file comes from. If that is what you are looking at, this is the wrong page — the mark needs removing rather than adding, and the page that does that is linked below.
What the page will not do is reformat your file on the way through. It does not touch CRLF line endings, cue numbers, timings or the text of any cue, and it does not decide your file's encoding for you: a file that is not UTF-8 is a different problem, and there is a page for that too. What it does is add one character at the very front, and if the character is already there it leaves the file alone rather than adding a second one, so running the page twice gives the same file as running it once.
The mark is added to the file you download. The two panes on this page can therefore be identical to the eye — an invisible character is exactly what an invisible character looks like — and the honest way to check the result is to look at the first three bytes in a hex viewer or at the file's encoding in your editor's status bar. All twelve subtitle formats this site handles can carry a mark, because a mark is a property of the file's opening bytes and knows nothing about cues. Nothing is uploaded at any point: the file is read, changed and written inside your browser.
Examples
An ASCII subtitle file, with a mark in front
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 expected text begins with an invisible character: U+FEFF, the three bytes EF BB BF, before the 1 of the first cue number. The two panes will look the same to you and that is not a rendering fault — the difference between these files is three bytes long and none of them have a shape. Download the result and open it in an editor that shows the encoding, or look at the first bytes in a hex viewer, and it is the first thing you see.
A Windows file, mark added and carriage returns kept
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 two things a Windows subtitle tool writes are a mark and CRLF line endings, which is why they get conflated — but they are separate, and this page writes only the first. Every carriage return in the expected file is the input's own, and the mark is added in front of them. A page that rewrote the line endings as well would silently reformat every file handed to it, which is precisely the kind of change nobody notices until a tool downstream cares.
A file that already carries a mark
Input
1
00:00:01,000 --> 00:00:02,000
Already marked.
Output
1
00:00:01,000 --> 00:00:02,000
Already marked.
The input already has a mark, so the output is the input byte for byte — the file keeps exactly one. The naive version of this page, which pastes a mark on without first removing what is there, produces a file with two, and a doubled mark is invisible in every editor while being a different file to anything that reads the opening bytes. Running the page on an already-marked file should be something you can do without thinking about it.
Frequently asked questions
What does adding a byte order mark to a subtitle file actually change?
One character at the very front of the file: U+FEFF, written as the three bytes EF BB BF in UTF-8. No cue is added, removed or edited, no timecode moves, the cue numbers and line endings come out as they went in, and the text of every line is untouched. If you diff the two files the only line that differs is the first one, and it differs by three bytes at its start.
Why do the two panes on this subtitle BOM page look identical?
Because the character being added has no shape. U+FEFF is a zero-width no-break space, so a pane that renders text the way your player would shows the same thing before and after. The change is real and it is in the file you download: the difference is the first three bytes. Your editor's encoding indicator, or a hex viewer showing EF BB BF at the start, is where to look for it rather than at the text.
Is the add BOM subtitle tool safe to run twice on the same file?
Yes. The page removes any mark already present before writing its own, so a file that already carries one comes back unchanged and a file that does not gets exactly one. Two runs give the same file as one run. This also means a file that has been through this page and then through a tool that added a second mark can be cleaned up by sending it through once, because only one survives.
Is the mark kept if I convert the subtitle file to another format afterwards?
Not by the conversion pages on this site, which write plain UTF-8 with no mark, so a mark added here is not carried across a format change. Order the work accordingly: convert first, then add the mark as the last step before delivery. That is also the more sensible order in general, since the mark is a property of the finished file rather than of the subtitle content.
Does adding a mark to a subtitle file change its line endings?
No. A Latin-1 or UTF-8 mark is one character placed before the first byte of the file and has no effect on what follows it. A Windows file full of CRLF stays full of CRLF, a Unix file stays on LF, and a file with mixed endings comes out with the same mixture it arrived with. Changing line endings is a different page, and it is a bad idea to have one page quietly do both.
Which subtitle formats can be given a byte order mark?
All twelve this site handles: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON and CSV. The mark is about the file's opening bytes rather than about the subtitle format, so there is nothing format-specific to get right — even a plain text transcript, which has no timeline at all, can carry one.