Convert Subtitle Line Endings
Or paste subtitle text
Options
Every line in the file ends with either one invisible character (LF) or two (CRLF). Players, editors and subtitle tools all read both, so this is almost never the reason a subtitle file misbehaves — the two reasons it is are a build pipeline or a strict parser that rejects the other one, and a diff tool that shows every single line as changed because the endings differ. LF is the choice here by default because it is what Unix, macOS and the web use, and because a file that already has it is left alone. Picking CRLF converts both kinds of existing ending, so a file with a mixture comes out consistent.
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 line ending is the character or pair of characters that ends a line, and there are two of them in ordinary use. Unix systems end a line with one character, LF; Windows ends it with two, CR then LF. Both look the same on screen, and both are read the same way by subtitle players, which is why this is one of those differences that stays invisible until something downstream cares about it.
What cares: version control, where every line of a file can appear changed because the endings changed; build scripts and pipelines that strip the last character of a line and are left with a stray carriage return when they expected a newline; tools that split a file on LF and end up with a trailing carriage return glued to the last field; and any delivery specification that names one of the two. A subtitle file that has to be diffed against another, or concatenated with another, is a file whose line endings are part of its interface.
The page is deliberately uniform about what it produces. A file with mixed endings — some lines CRLF because it was edited on Windows, some LF because it was edited anywhere else — comes out entirely in the style you picked, because the page normalises line endings to LF first and then applies your choice. That is not the same as converting the endings that are already correct and leaving the rest alone: it means the answer to "which style is this file" stops depending on which line you look at, which is the only version of the answer that is useful to a script.
A bare carriage return, the line ending of a Mac before OS X, is handled along with the rest. Nobody chooses it any more, but files still turn up carrying it, and a file whose lines end that way is a single line to every tool that only looks for LF. Normalising first means those files come out right rather than coming out as one enormous cue.
The two panes on this page are the one place in this family where the difference is directly visible: a line ending is a real character, and a file with double-spaced-looking lines in a viewer that does not hide them is a file with CRLF. All twelve formats are accepted, because a line ending is a property of the text rather than of the subtitle format — a plain transcript has lines too. Nothing is uploaded, and the file is read, changed and written in your browser.
Examples
Converting a Unix file to Windows endings
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.
Every line ending becomes two characters, including the empty line between the cues — that blank line is a line ending too, and a conversion that skipped it would leave a file whose cue separator is still a bare LF. The expected text spells the endings out as CR LF pairs so the count can be read straight off it, and nothing else in the file has moved.
Converting a Windows file back to Unix endings
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 direction with the visible consequence. A file that keeps a stray carriage return shows up in some editors as having an empty line after every line, and in a shell pipeline as a carriage return stuck to the end of the last field. The video, the timings and the text are identical in both files; the difference is a character at the end of each line, and this is the direction that removes it.
A file edited on two machines, made uniform
Input
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Output
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
The same file touched on two machines: some lines end CRLF, some LF, and one cue separator is written each way. The output is uniform, which is the point — the file no longer means something different depending on which line you read. A naive search-and-replace gets this case wrong in both directions: it leaves the LF lines alone going one way and produces a doubled carriage return going the other.
Frequently asked questions
How can I see which line endings a subtitle file uses?
In most editors the line ending style is shown in the status bar, as LF, CRLF or a mixture. From a shell, a file whose lines end CRLF shows a trailing carriage return on each line when you look at it with a tool that makes control characters visible. The direct test is to look at the bytes at the end of a line: a single 0A is LF and the pair 0D 0A is CRLF.
What does this page do with a subtitle file that has mixed line endings?
It makes them all the same. The file is normalised to LF first and then converted to the style you picked, so a file where some lines end one way and some the other comes out completely uniform rather than partly converted. Files get into that state by being edited on more than one machine, and the mixture is exactly what makes a diff against another copy of the file unreadable.
Do line endings change the subtitle timings or the cue text?
No. The cues, their numbers, their start and end times and the words in them are all identical before and after; what changes is the one or two characters at the end of each line. A player reads both files the same way, which is why this is a conversion you can make for a delivery requirement without worrying about the subtitles themselves.
Should I convert subtitle line endings to LF or CRLF?
LF unless something in front of you names CRLF. It is what Unix tools, most build pipelines and the WebVTT specification expect, and it makes a file one byte shorter per line. Choose CRLF when a delivery specification or a Windows-only tool asks for it, and note that the choice is per file rather than global: a subtitle file that is delivered on its own can differ from the rest of the project.
Why does converting to CRLF also change the blank line between subtitles?
Because that blank line is a line, and its ending is a line ending like any other. SRT separates cues with an empty line, so a file converted to CRLF whose cue separator stayed a bare LF would have one line ending of a different kind in the middle of a uniform file — which is precisely the mixture this page exists to remove. The same applies to the last line of the file.
Are old Mac carriage returns converted as well?
Yes. A file whose lines end with a bare carriage return, the style used by Mac OS before OS X, is normalised along with everything else, so it comes out in the style you picked instead of staying as one long cue. There is no option for CR on the panel because nobody writes files that way any more, but files that already are that way are read and rewritten correctly.