The Complete SRT Formatting Rules for Valid Subtitle Files

Q: Can SRT Files Include Bold or Colored Text?

SRT supports basic HTML-derived tags like , , , and , but rendering support varies significantly between players, so test any styled file on your target platform before relying on it.

Every valid SRT cue needs four things in this exact order: a sequential number, a timestamp line formatted as HH:MM:SS,mmm --> HH:MM:SS,mmm, one or two lines of subtitle text, and a blank line before the next cue. The single rule that breaks more SRT files than anything else is the comma. SubRip timestamps use a comma before milliseconds, not a period, and most parsers reject the file the moment they hit a period instead.

Here’s a minimal, valid cue you can paste into any text editor and save as a .srt file to test a player or online validator:

1
00:00:01,000 --> 00:00:04,000
Hello, and welcome to the show.

A file with one correct cue and a comma in the right place will play in nearly any modern video platform. A file with a hundred cues and one period where a comma should be will fail to load at all.

Before you build out a full file, watch for these four failure points:

Comma vs. period: 00:00:01,000 is correct; 00:00:01.000 breaks most parsers.
Missing blank line: skip the blank line between cues and many players merge two subtitles into one garbled block.
Wrong encoding: saving in the wrong character set corrupts accented characters and non-Latin scripts.
Non-sequential numbering: not every player cares, but some validators flag it, so keep counters in order.

Key Takeaways

Valid SRT files depend on exact timecode syntax, consistent structure, and UTF-8 encoding, and most upload failures trace back to just a handful of fixable mistakes.

Point	Details
Comma, not period	Timecodes must use `HH:MM:SS,mmm` with a comma before milliseconds, never a period.
Four parts per cue	Every cue needs a number, timestamp line, text, and a blank line separator.
UTF-8 without BOM	Save files as UTF-8 without a byte order mark to avoid garbled text and first-cue errors.
Keep lines short	Limit captions to two lines, roughly 32 to 42 characters per line, for mobile readability.
Validate before uploading	Check for overlapping timestamps and missing blank lines, or use a tool like Youtube to Transcript for a pre-formatted export.

What Are the Core SRT File Formatting Rules?
How Do You Write a Timecode Without Breaking the Parser?
What Text Styling Does SRT Actually Support?
How Long Should Each Subtitle Line Be?
How Should You Encode and Name an SRT File?
What Can’t SRT Do, and When Should You Use Something Else?
What Are the Most Common SRT Mistakes, and How Do You Fix Them?
How Do You Create, Save, and Upload an SRT File?
What’s the Fastest Way to Get a Correctly Formatted SRT File?
What Production Work Teaches You About SRT Files
Get a Correctly Formatted SRT Without Typing a Single Timecode
Sources
FAQ

What Are the Core SRT File Formatting Rules?

An SRT file, short for SubRip Subtitle, is a plain-text sidecar file that pairs a block of dialogue with a start and end time so a video player knows exactly when to show and hide each line. It carries no video or audio data itself. It just rides alongside your video file, and the player reads it in sync.

Every cue in that file follows the same four-part structure, and understanding these parts is the whole game when it comes to SRT file formatting:

Numeric counter. A whole number, starting at 1, marking the sequence of the cue. Most players use it only as a label rather than for actual sequencing logic, but you should still count sequentially, because some validators and editing tools flag gaps or duplicates as errors.
Timestamp line. Two timecodes separated by an arrow, showing exactly when the subtitle appears and disappears.
Subtitle text. One or two lines of dialogue, sound description, or speaker label.
Blank line. An empty line that tells the parser “this cue is done, start reading the next one.”

Skip any one of these four and you risk a broken file. Skip the blank line specifically, and you’ll often see two unrelated lines of dialogue crammed into a single subtitle on screen, which is confusing for anyone reading captions in real time.

Here’s a longer example with three cues, formatted the way a captioning tool would export it:

1
00:00:00,500 --> 00:00:03,200
Welcome back to the channel.

2
00:00:03,400 --> 00:00:07,100
Today we're covering subtitle formatting.

3
00:00:07,300 --> 00:00:10,800

[upbeat music]

>> Let’s get started.

Notice the gap between cue 2 ending at 00:00:07,100 and cue 3 starting at 00:00:07,300. That small buffer avoids overlap, which is a detail we’ll come back to.

Think of the blank line as a period at the end of a sentence. Leave it out and the reader (or in this case, the parser) doesn’t know where one thought ends and the next begins.

How Do You Write a Timecode Without Breaking the Parser?

The exact syntax is HH:MM:SS,mmm, two digits each for hours, minutes, and seconds, followed by a comma and three digits for milliseconds. So 01:23:45,678 means one hour, 23 minutes, 45 seconds, and 678 milliseconds. Miss a leading zero, and you’ll turn 00:00:05,000 into 0:00:5,000, which many parsers won’t recognize.

The separator between the start and end time follows its own strict pattern too: a space, two hyphens, a greater-than sign, and another space, written as -->. Not an em dash. Not a single hyphen. Two literal hyphen characters plus a greater-than sign, according to the Library of Congress’s format documentation for SubRip.

A few of the most common timecode mistakes, and how to catch them:

Using a period instead of a comma: 00:00:01.000 looks nearly identical to a valid timecode but fails to parse in most software, and this single character swap is one of the most frequent causes of SRT upload failures.
Dropping leading zeros: 0:0:5,000 should read 00:00:05,000. Always pad every field to its full digit count.
End time earlier than start time: a cue that reads 00:00:10,000 --> 00:00:08,000 is logically invalid and will either be skipped or cause a rendering glitch.
Overlapping cues: if cue 2 starts before cue 1 ends, some players show both simultaneously, while others just cut the first one off early. Neither is what you want.

Pro Tip: If a subtitle file “almost works” but one line vanishes or two lines run together, open the file in a plain text editor and search for periods inside timecodes. Nine times out of ten, that’s the culprit.

What Text Styling Does SRT Actually Support?

SRT supports a small set of HTML-derived tags:  for bold,  for italics,  for underline, and  for basic color changes. That’s the entire styling toolkit, and support for even these tags varies significantly from one player to another, since the original SubRip specification never formally standardized styling behavior.

Because SRT has no built-in way to indicate who’s speaking or what sound is playing, captioning conventions fill that gap using plain characters instead of markup:

Square brackets for non-speech sounds: [phone ringing], [applause], [music playing].
Double arrows for speaker changes: >> John: I think we should go. The >> signals a new speaker without needing a name every time.
Speaker labels in caps or with a colon: useful in interviews or multi-person dialogue where viewers need a quick way to track who’s talking.

These conventions matter for accessibility, not just style. A viewer who is deaf or hard of hearing relies on bracketed sound cues and speaker markers to follow a scene the way a hearing viewer follows tone of voice and ambient noise. The University of South Carolina’s captioning guidelines recommend exactly this pattern for accessible caption files.

Resist the urge to over-style your captions. Bold and color can highlight emphasis, but stacking multiple tags on one line often renders inconsistently, and some platforms strip all formatting tags on import regardless of what you wrote.

Pro Tip: Nested tags like text frequently break during import into video editors or captioning platforms. If you need both bold and italic, test the exact platform first, because many will only honor the outer tag and silently drop the inner one.

How Long Should Each Subtitle Line Be?

Keep each subtitle to two lines maximum, with a character count per line suitable for reading on mobile and desktop devices. That range comes from caption editing guidelines published by James Madison University, and it holds up well across mobile and desktop screens alike. Cram in more text than that, and viewers on a phone screen either can’t read it in time or the line wraps awkwardly.

Reading speed is the other half of the equation. Most captioning standards target a comfortable reading pace of around 160 to 180 words per minute, meaning a 12-word sentence needs roughly four to five seconds on screen to be readable without feeling rushed.

Guideline	Recommended Range
Characters per line	32–42
Lines per cue	1–2 max
Reading speed	160–180 WPM
Display duration	1–4 seconds

To turn word count into display time, divide the word count by your target reading speed (in words per second), then round up slightly to avoid cutting it too close. At 170 WPM, that’s roughly 2.8 words per second. A ten-word line needs about 3.5 seconds; round that up to 4 seconds and you’ve got a comfortable, readable cue.

Keep display time for each cue within a reasonable range to ensure viewers can read the text comfortably; avoid durations too short or too long for readability. Static text that lingers too long reads as sluggish, even if it’s accurate.
Split long sentences into two cues rather than cramming them into one dense block of text.

How Should You Encode and Name an SRT File?

Save every SRT file as UTF-8 without a byte order mark, and you’ll avoid the two most common encoding headaches: garbled accented characters and a corrupted first subtitle cue. Older captioning tools sometimes defaulted to Windows-1252 encoding, which works fine for basic English text but breaks the moment you introduce accented letters, non-Latin scripts, or special punctuation, according to background on the SubRip format’s encoding history.

A BOM, or byte order mark, is a tiny invisible character some text editors add at the start of a UTF-8 file to signal its encoding. The problem is that many SRT parsers don’t expect it, and it can attach itself to the very first number in your file, turning 1 into an unreadable character that some players interpret as a broken index. Saving without a BOM sidesteps this entirely.

A few more practical rules for naming and saving your file:

Match the base filename to your video file when you want a player to auto-detect the subtitle track. If your video is episode-04.mp4, name the subtitle episode-04.srt.
Always use the .srt extension, lowercase, with no extra periods or spaces in the filename.
Watch your line endings. Windows systems often default to CRLF (carriage return plus line feed), while Mac and Linux tools typically use LF only. Most modern players handle either, but if you’re troubleshooting a file that won’t parse, checking line-ending consistency is worth the two minutes it takes.

What Can’t SRT Do, and When Should You Use Something Else?

SRT has no way to position text on screen, no support for animation or karaoke-style word highlighting, and no metadata fields for language tags or styling defaults. It’s a plain-text format built for one job: pairing text with timing, and it does that job well, but nothing more.

That limitation is also its biggest strength. Because SRT asks so little of the player reading it, it’s supported almost everywhere, from YouTube to VLC to nearly every video editor on the market. When you need more control, though, forcing SRT to do something it wasn’t built for usually backfires, and converting to a format designed for that purpose works better than fighting the file type.

Feature	SRT	WebVTT	ASS
Text positioning	Not supported	Supported	Supported
Styling control	Minimal (basic tags)	Moderate (CSS-like)	Extensive
Native browser support	Limited	Strong	Weak
Animation/karaoke effects	Not supported	Limited	Supported

If your project needs on-screen positioning for accessibility reasons, such as keeping captions from covering a speaker’s face, WebVTT is generally the better fit since browsers support it natively. If you’re doing anime-style fan subtitling with karaoke timing and heavy visual effects, ASS gives you far more control. For everyday captioning, transcript exports, and broad compatibility, SRT remains the practical default.

What Are the Most Common SRT Mistakes, and How Do You Fix Them?

Nearly every broken SRT file traces back to one of a handful of repeatable mistakes, and once you know what to check, fixing them takes minutes rather than hours.

Run through this checklist before uploading any subtitle file:

Timecodes use a comma before milliseconds, not a period.
Every cue is followed by a blank line, including the very last one in the file.
Index numbers are sequential, without skipped or duplicated numbers.
No cue’s end time falls before its start time.
No two cues overlap in time.
The file is saved as UTF-8, ideally without a BOM.

According to a breakdown of common SRT upload failures, the majority of parsing errors trace back to exactly these six issues, most often the comma-versus-period mistake and missing blank lines.

To validate a file before you rely on it:

Open the file in a plain text editor (not a word processor, which can silently change encoding or punctuation) and scan for periods in timecodes.
Check that every cue block ends with a genuine blank line, not just a line break within the text.
Run the file through an online SRT validator or your captioning software’s built-in check feature, which will usually flag numbering gaps and malformed timecodes automatically.
Load the file into an actual video player and watch for cues that display too early, too late, or not at all.
For overlapping cues specifically, decide intentionally whether you want two lines shown at once (rare) or whether you need to trim the end time of the first cue so it closes before the next one opens.

Different players handle overlap differently. Some show both cues stacked, some just display whichever cue started most recently, and some throw an error. Since behavior isn’t consistent, the safest move is to never let cues overlap in the first place, leaving at least a small gap like the 200 milliseconds used in the earlier example.

How Do You Create, Save, and Upload an SRT File?

Building a valid SRT file by hand is entirely possible with nothing more than a plain text editor, though most people find a dedicated captioning tool faster once they’re working with more than a few cues.

Open a plain text editor (Notepad, TextEdit in plain text mode, or a code editor like VS Code).
Type each cue following the four-part structure: number, timestamp line, text, blank line.
Save the file with UTF-8 encoding, no BOM, and the .srt extension.
Rename the file to match your video’s filename if your platform expects sidecar subtitle detection.
Upload the file to your video platform or import it into your video editor.

For YouTube specifically, you’ll upload the SRT file through the Subtitles section of YouTube Studio, and the platform will auto-match timing to your video. After uploading, always preview the captions on the actual video, since sync issues and stripped formatting tags only show up once you watch it play back. YouTube tends to strip most styling tags on import, so don’t be surprised if bold or color tags simply disappear.

A short list of tools worth having on hand:

A plain text or code editor for quick manual edits and troubleshooting encoding issues.
A dedicated caption editor for building files with visual timeline controls instead of typing timecodes by hand.
An online or desktop validator to catch syntax errors before you upload.
A converter for moving between SRT, WebVTT, and other formats when a project’s requirements change.

What’s the Fastest Way to Get a Correctly Formatted SRT File?

If you’re working from a YouTube video and need a transcript or subtitle file without typing timecodes manually, Youtube to Transcript generates an SRT export directly from the video’s audio, with encoding and timestamp formatting already handled correctly. That skips the entire manual process of counting cues, formatting timecodes, and checking for comma errors by hand.

A few tools worth keeping in your workflow alongside it:

Plain text editors for manual fixes and quick syntax checks.
Caption editing software for fine-tuning timing visually rather than by typing numbers.
Format converters for switching between SRT, VTT, and other formats as project needs shift.

Pro Tip: Even with an automated export, open the file afterward and spot-check three things: the encoding (UTF-8, no BOM), that line breaks didn’t get mangled mid-sentence, and that timing lines up with fast-paced dialogue. Automated tools handle the syntax reliably, but pacing still benefits from a human read-through.

What Production Work Teaches You About SRT Files

Most guides treat SRT formatting as a set of syntax rules to memorize, but the syntax is the easy part. The habits that actually save time come from repetition, not reading a specification once.

Shorter cues beat longer ones almost every time, even when the character count technically fits the 42-character guideline. A dense 40-character line crammed with clauses reads slower than two clean 20-character lines, because viewers process short phrases faster than they process line wraps. If a sentence has a natural pause, that’s usually where the cue should split.

Non-speech markers get skipped more often than any other rule on this list, not because people don’t know about them, but because they’re easy to forget when you’re transcribing quickly. Build the habit of a second pass specifically to add [bracketed] sound cues and speaker markers, rather than trying to catch everything on the first draft.

Batch validation before delivery catches more errors than validating cue-by-cue as you go. Write the whole file first, then run it through a validator once at the end. Fixing five flagged errors in one pass is faster than stopping every ten cues to double check your own work.

The gap between a technically valid SRT file and a genuinely good one is almost entirely about restraint: fewer styling tags, shorter lines, and consistent spacing between cues. The format rewards simplicity because it was built for simplicity.

Get a Correctly Formatted SRT Without Typing a Single Timecode

Manually building an SRT file works fine for a two-minute clip, but it turns into hours of tedious timecode math the moment you’re captioning a 40-minute video. Youtube to Transcript solves that specific problem: it converts YouTube video audio into text and exports it directly as a properly formatted SRT file, with UTF-8 encoding and sequential timestamps generated automatically, even for videos that never had subtitles to begin with.

Beyond the export itself, the tool includes cloud storage so your transcripts stay accessible across devices, batch processing for handling multiple videos at once, and translation into more than 89 languages if your captions need to reach a broader audience. You can export to TXT and VTT as well, which is useful if a later project needs a different subtitle format than the one you started with.

If you’re a content creator, student, or marketer who needs a clean SRT file fast, install the Youtube to Transcript browser extension and run your first export today.

Sources

FAQ

How Do You Make an SRT File From Scratch?

Open a plain text editor, write each cue with a number, a timestamp line in HH:MM:SS,mmm --> HH:MM:SS,mmm format, subtitle text, and a blank line, then save the file as UTF-8 with a .srt extension. Tools like Youtube to Transcript can generate this structure automatically from a YouTube video’s audio.

What Programs Can Open an SRT File?

Any plain text editor can open an SRT file since it’s stored as readable text, and most video players and editors, including VLC, Premiere Pro, and YouTube Studio, can import it directly for playback or editing.

How Do You Format Subtitles Correctly?

Keep each subtitle to one or two lines with about 32 to 42 characters per line, use a comma before milliseconds in every timecode, and separate each cue with a blank line so players don’t merge adjacent subtitles together.

What Is the SRT Format for Subtitles?

SRT is a plain-text subtitle format consisting of sequential numbered cues, each with a start and end timestamp separated by an arrow, followed by the subtitle text and a blank line, with no support for advanced styling or metadata.

Can SRT Files Include Bold or Colored Text?

SRT supports basic HTML-derived tags like , , , and , but rendering support varies significantly between players, so test any styled file on your target platform before relying on it.