How to Edit an SRT File Without Breaking It

You have an SRT file, and something in it is wrong: a name is spelled three different ways, a caption sits on screen for half a second, or the whole thing shows up as garbled symbols the moment you upload it. Learning how to edit an SRT file is mostly about knowing which parts you can safely touch and which parts will silently break playback if you nudge them. This guide walks through the manual method in a plain text editor first, then the shortcuts worth taking when a file is beyond hand editing.

Step 1: Understand the anatomy of an SRT file

Open your .srt file in any text editor and you will see repeating blocks that look like this:

14
00:02:31,480 --> 00:02:34,120
We shipped the first version
on a Friday afternoon.

15
00:02:34,400 --> 00:02:37,900
Nobody recommends that, by the way.

Every block has four parts:

1. The index number. A plain integer, counting up from 1.
2. The timecode line. Start time, then a space, then an arrow made of two hyphens and a right angle bracket, then a space, then the end time. The format is HH:MM:SS,mmm. Note the comma before the milliseconds, not a period. That comma is one of the main differences between SRT and WebVTT, covered in this comparison of SRT and VTT subtitle formats.
3. The caption text. One or two lines, occasionally three.
4. A blank line. This terminates the block. It is not decorative. Without it, the next block is invisible to most players.

The safe rule: edit the text freely, edit timecodes carefully, and never delete a blank line between blocks.

Step 2: Open the file in the right editor

Do not open an SRT in Microsoft Word or Google Docs. Word processors add smart quotes, invisible formatting, and may refuse to save as plain text, all of which corrupt the file.

Use one of these instead:

• Windows: Notepad works. Notepad++ is better because it shows encoding and line endings in the status bar.
• macOS: TextEdit works if you switch it to plain text mode with Format then Make Plain Text. Sublime Text or Visual Studio Code are better.
• Linux: gedit, nano, or Visual Studio Code.
• Any platform: Visual Studio Code is the most forgiving option because it displays the encoding in the bottom right corner and lets you change it in one click.

If your operating system opens the SRT in a video player or refuses to open it at all, right click the file, choose Open With, and pick your text editor manually.

Step 3: Fix spelling, names and brand terms

This is the safest edit and usually the most valuable one. Automatic transcription reliably mangles proper nouns, product names, acronyms, and anything spelled unusually.

Do not fix these one at a time. Use find and replace:

1. Press Ctrl+H (Windows/Linux) or Cmd+Option+F (macOS in VS Code) to open find and replace.
2. Type the wrong spelling in the find field and the correct one in the replace field.
3. Turn on match case if the term is case sensitive, so replacing "ai" does not eat the "ai" inside "said" or "again".
4. Use Replace All.

Work through a list: your company name, your product name, guest names, technical terms, recurring acronyms. If you publish regularly, keep that list in a note and reuse it on every file.

One caution: never run a find and replace on a string that could appear inside a timecode. Replacing "00" or "," across the whole file will destroy every timing line at once.

Step 4: Fix line length and reading speed

Two captions can be spelled perfectly and still be unreadable. The two things to check:

Line length. Aim for roughly 32 to 42 characters per line, and no more than two lines per caption. Longer lines overflow on phones and get truncated by some players. To break a line, just press Enter inside the caption text. Break at natural grammatical points:

Good:
We shipped the first version
on a Friday afternoon.

Bad:
We shipped the first
version on a Friday afternoon.

Break after punctuation, before a preposition, or between clauses. Never split a name or a number across two lines.

Reading speed. A caption that is on screen for under one second is a flash the viewer cannot read. Subtract the start time from the end time in the timecode line and check that a long caption gets enough time. If a caption is too short, extend its end time, but only up to the start time of the next block. Two overlapping blocks will make captions stack or flicker on some players.

To extend a caption, edit only the second timecode:

Before: 00:02:31,480 --> 00:02:32,100
After:  00:02:31,480 --> 00:02:34,120

Leave the arrow, the spaces, and the comma exactly as they are.

Step 5: Shift timings when the whole file is out of sync

If every caption is late or early by the same amount, you do not need to touch each block. You have two options.

The manual option is to open the file in a free subtitle editor such as Subtitle Edit or Aegisub, which both include a time shift function where you enter an offset like -1.5s and apply it to all lines at once.

The blunt option, if the offset is a clean number of seconds and the video is short, is to edit each timecode by hand. This is tedious and error prone beyond about twenty blocks, which is exactly when re generating the file becomes the better call.

If the drift grows as the video goes on, so the captions start correct and end minutes off, the file was generated against a different frame rate or a different cut of the video. Shifting will not fix that. Regenerate the subtitles from the current video file instead.

Step 6: Save with the correct encoding

This is the step that causes the most mysterious failures. If your captions display as é or ’ or a row of question marks, the encoding is wrong.

Save the file as UTF-8, and prefer UTF-8 without BOM. A BOM is a byte order mark, a few invisible characters at the very start of the file. Some players read that BOM as part of the first index number, which means block 1 is never recognised and your first caption silently disappears.

In Visual Studio Code, click the encoding label in the bottom right, choose Save with Encoding, then pick UTF-8. In Notepad++, use Encoding then Convert to UTF-8 (without BOM). In Notepad on Windows, choose Save As and set the Encoding dropdown to UTF-8.

Also confirm the file extension is still .srt and not .srt.txt. Windows hides known extensions by default, so a file that looks correct in Explorer may have picked up a second extension on save. Turn on file name extensions in the View tab to check.

Step 7: Test the file before you publish it

Never upload straight from the editor. Drop the SRT next to your video file, give both the same base name, and open the video in VLC. VLC will load the subtitle automatically, and any structural break will show up immediately as missing or misaligned captions.

Once it plays cleanly in VLC, upload it to your platform. If you are publishing to YouTube, the upload flow and the settings that matter are covered in this guide to uploading an SRT file to YouTube.

Common problems and how to fix them

Captions do not appear at all. Usually a missing blank line between blocks, or a BOM at the start of the file. Open the file, confirm the first character is the digit 1, and re save as UTF-8 without BOM.

Only some captions appear. Check the index numbers. If a block was deleted by hand, the numbering may have gaps or duplicates. Renumber sequentially from 1. Most players tolerate gaps, but strict ones do not.

Accented characters look wrong. Encoding again. Re save as UTF-8. If the damage is already baked in, the fix is to go back to the original file, not to hand correct each symbol.

Timecodes are ignored. Check for a period instead of a comma before the milliseconds. 00:02:31.480 is WebVTT syntax and will fail in a strict SRT parser.

Captions overlap or flicker. One block's end time is later than the next block's start time. Pull the earlier end time back so it lands before the next start.

Everything is a single wall of text. The file was saved with the wrong line endings, common when moving files between Windows and macOS. In Notepad++ or VS Code, switch line endings to CRLF and re save.

When re transcribing beats hand editing the file

Hand editing pays off when you have a short list of fixes: a few names, a handful of line breaks, one timing nudge. It stops paying off fast.

Regenerate instead of editing when the transcript has errors scattered through every other block, when the timings drift progressively, when you cut or reordered the video after the subtitles were made, or when you need the same content in another format. Fixing a hundred blocks by hand takes longer than producing a clean file from the current video and applying your standard find and replace list once.

That regeneration step is where a transcription tool earns its place. Tapescribe takes a link or an uploaded file and returns a transcript with subtitles in SRT, VTT and TXT, timed against the video you actually have now, so you start from an accurate file rather than repairing an old one. If you want the full workflow for that, see how to create an SRT file from a video automatically.

Frequently Asked Questions

Can I edit an SRT file on my phone?

Yes, but carefully. Most mobile note apps will not save plain text with the correct extension, and some add formatting that corrupts the file. Use a dedicated text editor app that lets you control the file extension and encoding, or wait until you are at a computer for anything beyond a one word fix.

What happens if the index numbers are out of order?

Many modern players, including VLC and YouTube, ignore the index numbers entirely and read the timecodes instead, so an out of order file often still works. Stricter parsers and some broadcast systems will reject it or drop blocks. Renumbering sequentially from 1 costs nothing and removes the risk.

How do I remove a caption block completely?

Delete all four parts: the index number, the timecode line, the text, and the trailing blank line, leaving no empty gap where the block was. Then renumber the following blocks so the sequence stays continuous. If you leave the blank lines behind, some players read them as an empty caption and flash a blank box on screen.

Should I edit the SRT or the original transcript?

Edit the transcript when the wording itself is wrong across the whole file, because you fix each error once and regenerate clean timings. Edit the SRT directly when the words are right and only the presentation needs work, such as line breaks, timing nudges, or removing a caption. The general rule is that content problems belong upstream and formatting problems belong in the SRT.

An SRT is a simple format, and that simplicity is what makes it fragile: one missing blank line or one stray byte at the top of the file is enough to make every caption vanish. Keep a copy of the original before you start, make your text fixes with find and replace rather than by hand, save as UTF-8 without BOM, and always play the result in VLC before you upload it. If the list of fixes runs longer than a dozen blocks, regenerating the file is almost always faster than repairing it.