Key Takeaways
Decide first whether the subtitles are painted into the picture or shipped as a separate file. Burned-in subtitles survive anywhere and can never be turned off. A sidecar file, usually a
.srt, can be switched off, edited later and read by search engines, but only if the platform accepts uploads. After that the sequence is the same every time: get the text, split it into timed cues, read it back against the video, then upload or export. The file is plain text, so fixing it is easy.
You finished the edit. Now someone wants captions, or you’ve noticed that most people watch with the sound off, and you’re staring at an export dialog that doesn’t obviously have a subtitle box in it. That’s normal. Subtitles aren’t part of the video in the way music and colour grading are. Most of the time they’re a separate thing entirely, living in their own file, with their own format and their own rules.
So there’s a choice to make before you write a single line of text, and it’s the choice that determines everything after it. Nearly everyone makes it by accident. Here it is on purpose.
Burned in, or sitting alongside
There are two ways to get words onto a video.
Burned-in subtitles are painted into the picture when you export. The pixels of the text become pixels of the video, the same as a logo or a lower third. They are always visible. They cannot be turned off, resized, restyled or translated by the viewer, and if you got a word wrong you have to re-export the whole video to fix it. In exchange, they work everywhere with no cooperation from anyone: every player, every platform, every re-upload, every screen recording of your video that someone else makes.
A sidecar subtitle file sits next to the video as its own separate file. The player reads it and draws the text on top at playback time. The viewer can switch it on and off. You can fix a typo by editing a text file and re-uploading it, without touching the video. You can add a second language later by adding a second file. Nothing is baked into the picture, so the video underneath is untouched.
The catch is that the sidecar route depends entirely on the destination. Platforms differ in whether they’ll take an uploaded subtitle file at all. Some will, happily, and will show a caption toggle to the viewer. Some won’t accept one under any circumstances. Where a platform doesn’t accept a subtitle file, burning them in during export is the only route you have, and no amount of formatting the file correctly will change that.
Check what your destination accepts before you build anything. If you’re posting the same video to two places and one takes a file and one doesn’t, you may genuinely need two exports: a clean one with a sidecar file, and a burned-in one. That’s tedious and it’s also the honest answer.
What a subtitle file actually contains
A SubRip file – extension .srt – is the most widely accepted sidecar format, and it’s the one to use unless you have a specific reason not to. Its contents are almost boringly simple. Each cue is four things in order: a number, a line of timings, one or more lines of text, then a blank line. Then the next cue starts.
The timings are written as hh:mm:ss,mmm – hours, minutes, seconds, then milliseconds after a comma. The comma matters. A player that expects a comma and finds a period may reject the file or skip the cue, and the failure often looks like nothing happening at all rather than an error message. If you want the format explained field by field, there’s a fuller breakdown of the SubRip format worth reading once.
WebVTT – extension .vtt – is the other format you’ll meet. It starts with the word WEBVTT on a line of its own, and it separates milliseconds with a period rather than a comma. Cue numbers are optional. Beyond that it can do things SubRip cannot: position a cue somewhere other than the bottom centre, and carry styling information. If you need a caption to move out of the way of an on-screen graphic, WebVTT is how you’d say so.
If you have a WebVTT file and the platform wants SubRip, converting is straightforward, but be clear about what happens. The timings survive. The text survives. The positioning, the styling and any metadata are dropped, and they are dropped permanently, because SubRip has nowhere to put them. This isn’t a bug in the converter. The destination format simply has no field for that information. Convert the direction that loses nothing when you can, and when you can’t, expect the captions to land in the default position at the bottom.
The sequence: text, timings, check, upload
Once you know which route you’re taking, the work itself is always the same four steps, in the same order.
- Get the text. Every word that’s spoken, written down.
- Split and time it. Break the text into cues and give each one a start and an end.
- Read it back against the video. Watch it play with the subtitles on and fix what’s wrong.
- Upload the file, or export with it burned in.
Step one is the slow part if you do it by typing. You can transcribe by hand, which is accurate and takes several times the length of the video, or you can have the audio transcribed automatically and then correct it, which is faster and produces mistakes you have to hunt for – usually names, jargon and anything said over a loud background. Automatic transcription with a careful read-through is the right default for most people. A browser-based subtitle generator handles the splitting and timing side once you have text.
SozAI is a transcription app for iOS, Android and macOS that turns audio files, video files, recordings and YouTube links into text with speaker labels and translation across 99+ languages; the browser tools on the site handle subtitle files and counting but don’t transcribe audio themselves. It’s one option among several – if your editing software already produces a usable transcript, use that instead and skip the extra step.
If what you have is a flat wall of text with no timings at all, a plain text to SRT converter will do the mechanical part of splitting it into cues and writing the timing lines in the right shape. You’ll still need to nudge the timings against the video afterwards. No tool can guess where the speaker paused from text alone.
How long a cue should stay on screen
Timing is where amateur subtitles announce themselves, and the two failure modes are opposites.
A cue that’s on screen for under roughly a second is hard to read. The eye needs time to find the text, take it in and return to the picture, and under a second there isn’t enough of it. The viewer gets a flash of something and a vague sense they missed a word. This usually happens when a transcript has been split at every comma, or when a short interjection – a yes, a name, a laugh – has been given its own cue that matches the exact length of the sound.
A cue that runs past about eight seconds is the other problem, and it’s almost always a sign that two sentences got merged into one. Long cues sit there after the viewer has finished reading them, which is mildly annoying, but the real damage is that the second sentence appears on screen well before it’s spoken. The text and the audio drift apart and the viewer starts reading ahead instead of watching.
Aim for cues that comfortably fit between those two edges, split at natural sentence and clause boundaries rather than at fixed word counts, and let the picture breathe between them. When you’re unsure whether a cue is too long, read it aloud at the speed the person actually speaks. If you run out of breath, it’s two cues.
Checking the file before you upload it
A subtitle file is plain text. You can open it in any text editor on any machine, read it top to bottom, and change anything you like. This is the single most useful thing to know about subtitles, because it means the fastest fix for a wrong word is almost never reopening the editing software, re-finding the cue in a timeline and re-exporting. It’s opening the file, changing the word, saving.
Two kinds of thing go wrong, and they need different checks.
Structural problems stop the file from loading. A missing blank line between cues, a period where a comma belongs in the timings, an end time earlier than its start time, cues that overlap each other. These are invisible to a human skim and obvious to a machine, which is what an SRT file validator is for. Run the file through one before you upload it and you’ll catch the class of error that otherwise shows up as captions silently not appearing.
Content problems only surface when you watch. Names spelled wrong, a caption landing half a second late all the way through, a line that’s technically correct but reads badly. Play the video with the subtitles on, at normal speed, all the way to the end, and watch the text rather than the picture. It takes exactly as long as the video and there’s no shortcut.
What this won’t fix
Automatic captions generated by a platform are not the same as a subtitle file you made. They’re generated from the audio without your involvement, they’re often wrong on the words that matter most – product names, people’s names, technical terms – and you generally have limited control over them. Where you can upload your own file, doing so replaces guesswork with something you’ve read. Where you can’t, burned-in subtitles are the only way to guarantee the words on screen are the words you chose.
Burned-in subtitles are permanent in a way people underestimate. Once exported, the text is part of the picture. You cannot translate that video, you cannot offer it without captions, and a viewer on a small screen cannot make the text bigger. If there’s any chance the video will be reused, subtitled in another language, or handed to someone else to work with, keep a clean master export and the subtitle file separately, even if the version you post today has the words burned in.
And converting between formats will keep costing you the same thing every time. Going from WebVTT to SubRip drops positioning and styling, permanently, because there’s nowhere to put them. If you built captions that dodge an on-screen graphic and then convert to SubRip for a platform that demands it, those captions will land in the default position and cover the graphic. Knowing that in advance is better than discovering it in the published video.
