Change Subtitle Colour
Or paste subtitle text
Options
Pick the colour the whole file turns. Existing colours on a line are replaced rather than stacked, so one run leaves exactly one colour per line; bold, italic, underline and karaoke timings are left alone. Only #rrggbb is written — that is the one spelling all nine accepted formats can carry exactly. Not every player draws inline colour, and SRT has no standard for it: the file will hold the colour, but whether it shows is up to the player.
This page paints every line of a subtitle file in one colour. It reads the file as what it actually is rather than by extension, so the same run works on nine formats, and each of them receives the colour in the notation it already understands: `<font color="#rrggbb">` in SRT, WebVTT, SBV and SAMI, an override block in ASS and SSA, a `<span tts:color>` in TTML, the tag array in JSON, and the same inline markup inside the quoted cells of a CSV.
The colour you pick replaces what was there rather than stacking on top of it. A line that arrived partly green comes back wholly in the new colour — one range over the whole line instead of a `<font>` inside a `<font>`, which some players render as the inner colour and others ignore entirely. Bold, italic, underline and karaoke timing are left where they are, and a styled range keeps covering exactly the characters it covered before.
It is one colour for the whole file by design. Subtitle colour is usually a delivery decision — a house white, a yellow that survives a bright scene, a colour reserved for one kind of speaker — and a file that needed two colours would need someone to decide which lines take which, which is a job for a text editor rather than a single value on a panel. A cue with no text in it gets nothing: there is no range to paint, and a zero-length colour range would be a tag the size of nothing.
Nothing is uploaded and nothing leaves the browser tab. Colour is one of the few pieces of styling a subtitle file can carry without a renderer beside it, but whether the viewer sees it is the player's call — this page writes the marker, and the FAQ below says plainly which side of that line it stands on.
Examples
Two plain SRT cues
Input
1
00:00:01,000 --> 00:00:02,000
Hello there.
2
00:00:03,000 --> 00:00:04,000
Second line.
Output
1
00:00:01,000 --> 00:00:02,000
<font color="#ffcc00">Hello there.</font>
2
00:00:03,000 --> 00:00:04,000
<font color="#ffcc00">Second line.</font>
One `<font>` per line, wrapped around the whole of it, and the timecodes and blank lines are exactly as they arrived. The tag is a range over the line rather than a property of the cue, which is why a cue that holds two hard-wrapped lines gets two tags rather than one that spans the break.
A line that already carries a colour and an italic
Input
1
00:00:01,000 --> 00:00:02,000
<i>Hello</i> <font color="#00ff00">there</font>.
Output
1
00:00:01,000 --> 00:00:02,000
<font color="#ffcc00"><i>Hello</i> there.</font>
The green range is removed before the new colour goes on, so the result is one `<font>` around the line with the italic still inside it — not a `<font>` inside a `<font>`, where the nesting rules depend on the player and the outcome is quietly different on each. What was green is now the same colour as everything else, which is the honest reading of a panel that asks for one colour.
The same cue on an ASS file
Input
[Script Info]
ScriptType: v4.00+
[V4+ Styles]
Format: Name, Fontname, Fontsize
Style: Default,Arial,20
[Events]
Format: Layer, Start, End, Style, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,Hello there
Output
[Script Info]
ScriptType: v4.00+
[V4+ Styles]
Format: Name, Fontname, Fontsize
Style: Default,Arial,20
[Events]
Format: Layer, Start, End, Style, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,{\c&H0000CCFF&}Hello there{\c}
ASS has no `<font>`; the colour is an override code that opens before the text and is closed by a bare `{\c}` after it, so the rest of the line is not accidentally painted too. The stylesheet's `PrimaryColour` is not edited — the cue-level override is a stronger instruction and is the only one that would apply to this cue alone.
A cue with no text
Input
1
00:00:01,000 --> 00:00:02,000
2
00:00:03,000 --> 00:00:04,000
Hi.
Output
1
00:00:01,000 --> 00:00:02,000
2
00:00:03,000 --> 00:00:04,000
<font color="#ffcc00">Hi.</font>
The empty cue is left empty rather than being given a `<font>` around nothing. An empty cue is already a structural problem — the check pages will report it — and a markup tag with no text inside would not fix it, only hide it from a grep. The cue that does have text is painted normally.
Frequently asked questions
Which formats does this colour page write, and what does the marker look like in each?
Nine: SRT, WebVTT, ASS, SSA, SBV, SAMI, TTML, JSON and CSV. SRT, WebVTT, SBV and SAMI take `<font color="#rrggbb">`, ASS and SSA take a `{\c&H…&}` override closed by `{\c}`, TTML takes `<span tts:color="#rrggbb">`, JSON writes the colour as a tag range over the line, and a CSV keeps the same `<font>` markup inside its quoted text cell. Formats that have nowhere to put inline colour are not accepted by this page at all — an LRC or MicroDVD file has no colour syntax, so a run there would report a change and write nothing.
Why does the ASS output say `&H0000CCFF&` when I picked `#ffcc00`?
Because an ASS colour is written with its bytes in the opposite order: `&HAABBGGRR`, where the alpha comes first and then the blue, green and red pairs. `#ffcc00` is red 255, green 204, blue 0, so it becomes `00` alpha, `00` blue, `CC` green, `FF` red — `&H0000CCFF&`. The value is the colour you chose, and a player showing it shows the same yellow; the numbers only look rearranged because the format stores them back to front.
Will every video player actually show the new colour?
No, and that is the honest boundary of this page. `<font color>` is not part of the SRT specification — it is markup that most players tolerate and some ignore — and ASS override codes are honoured by libass-based players such as VLC and mpv but not by every hardware set-top box. The page writes the marker correctly and the result is verifiable in the file itself; whether a particular player shows it is that player's decision. If the colour has to be guaranteed on screen, it has to be burned into the picture, which is a different job.
What happens to colours the file already had?
They are replaced, not layered on top of. Every colour range on a line is removed first and then one range covering the whole line is added, so the result is a single `<font>` rather than a `<font>` inside a `<font>`. Nested colour tags are the case where players disagree most — some take the inner one, some the outer, some flatten both — so a file that has been through this page has one unambiguous answer in it.
Does the page colour individual words, or the whole subtitle file?
The whole file, one colour, every line. There is no per-cue or per-word scope on this page, and deliberately so: the panel holds a single value, and a run whose result depended on which cues you had clicked would not be reproducible from the file. A line that needs one word picked out is a text edit rather than a colour change, and this site's find and replace pages can do the targeted part of that.
Are bold, italic, underline and karaoke timings kept when the colour is applied?
They are kept, and their ranges stay attached to the same characters. Only colour ranges are removed and re-added; the other four kinds are untouched, so an italic word inside a line stays italic inside the new colour. On ASS that means the `{\i1}` and its closing `{\i0}` still sit in the same places around the text, with the colour override opened before them and closed after.