Adding subtitles to a video you already have

You have the video. It needs subtitles — because most feed viewers watch with the sound off, because someone asked for accessibility, or because the audio is fine but the accent is not universal. The editors that offer this want a subscription, and the free ones burn a watermark into the corner.

Subtitles are text timed to a video, and there are two entirely different ways to attach them. Which one you choose has more consequences than which tool you use, and the choice cannot easily be reversed later.

Burned-in or a separate file?

Burned-in (also called hardcoded or open captions) means the text is drawn into the picture. Every player shows it, no viewer can turn it off, and you cannot edit a typo without re-exporting the video.

A separate file — usually .srt or .vtt — is a plain text list of timings and lines that travels alongside the video. Players that support it let the viewer toggle it, search engines can read it, and fixing a mistake means editing a text file.

The rule that follows: upload a separate file wherever the platform accepts one, and burn in only when it does not. Social platforms mostly accept uploaded subtitle files, and the ones that do not — or that hide the toggle behind a menu — are where burning in earns its inflexibility.

An .srt file is simple enough to fix by hand, which is worth knowing because it removes any dependence on a tool:

1
00:00:02,400 --> 00:00:05,100
The first line of what was said.

2
00:00:05,300 --> 00:00:08,000
The second line, timed after it.

Numbers, a time range with a comma before the milliseconds, then the text. That is the entire format.

Getting the text in the first place

Three routes, and the right one depends on whether the words existed before the video did.

Automatic transcription. The platform generates subtitles at upload, or an app does it before export. Accuracy is good on clear speech in a quiet room and degrades sharply with background noise, overlapping speakers, accents and technical vocabulary. It is a first draft, never a final one.

Transcribe by hand. Slow — roughly four to six times the length of the video — and exactly right. Worth it only for short clips where precision matters.

Start from the script. If the narration was written before it was recorded, the subtitle text already exists and only needs timing. This inverts the whole problem: instead of correcting a machine's guess at your words, you are timing words you know are correct.

The third route is dramatically the cheapest when it is available. It is also the reason scripted narration compounds — a tool like SpeakFile produces the voice track from the same text that becomes the subtitle file, so the two cannot drift out of agreement.

Correcting an automatic transcript takes longer than people expect. Timing a script you already have takes minutes.

What automatic subtitles get wrong

Predictably, and in the same places every time.

• Proper nouns. Product names, brands and people. These are the words that most need to be right, and they are the ones the model has least reason to know.
• Numbers and units. "Fifteen hundred" versus "1,500", currency symbols, dates read aloud.
• Homophones in context. Their/there, its/it's — grammatically plausible and semantically wrong.
• Speaker changes. Two voices become one continuous block of text with no indication of who is talking.
• Where sentences end. Missing punctuation turns a subtitle into a run-on that is hard to read at speed.

Always read the transcript before publishing. The specific check that takes ten seconds and catches the worst of it: search the transcript for your own product name and see what the machine heard instead.

Timing and layout, which decide readability

Getting the words right is half of it. These are the conventions broadcast subtitling settled on, and they hold up.

1. Two lines maximum, around 32 to 42 characters each. Three lines cover too much picture and outpace reading speed.
2. At least one second on screen, ideally more. A caption that flashes is worse than none.
3. Break lines at natural phrases, not at the width limit. "the quick brown / fox jumped" reads worse than "the quick brown fox / jumped".
4. Keep it in sync or slightly early. Subtitles that lag the audio are far more distracting than ones that lead it.
5. Stay clear of the bottom edge. Interfaces overlay controls and usernames there, and a caption underneath them is unreadable.

Point five is the one that ruins otherwise good work on social platforms specifically. Positioning captions in the lower third rather than the very bottom keeps them clear of every platform's chrome.

What about a second language?

Translated subtitles are the strongest argument for keeping them in a separate file, because one video can carry several tracks and the viewer picks.

Three things to know before starting:

• Translate the subtitle file, not the audio. Working from a corrected transcript means you are translating text that is already right. Translating from the audio repeats every transcription error in a second language.
• Expect the text to change length. Translations commonly run longer or shorter than the original, and a line that fitted two lines in one language may need three in another. The timings usually survive; the line breaks rarely do, so re-break them rather than accepting the original splits.
• Right-to-left languages need checking in a player, not an editor. Arabic and Hebrew subtitles containing Latin words or numbers can render in a confusing order, and the only reliable check is watching the video with the track enabled.

There is also a decision about which language is the default. A file marked as default displays automatically; the rest wait for the viewer to choose. If most of your audience shares one language, mark that one and leave the others available — a video that opens with subtitles nobody in the room reads is worse than one with none showing.

For a single video in two languages this is twenty minutes of work on top of a transcript you already corrected. For a channel publishing weekly, it is the point at which keeping subtitle files under version control alongside the videos starts to pay for itself.

Doing it on a phone, without a subscription

The practical path, using what is available.

Let the platform generate them and correct them in its editor. Most social platforms produce a transcript at upload and let you edit it before publishing. This is free, and the edit step is where the quality comes from.

Use the built-in transcription in your notes or voice app to get the text, then time it into an .srt by hand for a short clip.

Assemble stills with text already on them. For anything that is really a slideshow, text on the images does the same job as subtitles and requires no timing at all — which is how tools like Stillora sidestep the problem entirely.

Check the result on a phone before publishing. Text that is comfortable on a laptop is often too small on the device where most people will watch it.

For anything longer or repeated, this becomes a workflow rather than a task, and the script-first approach pays back immediately. More in video tools, the transcription side in text tools, and general on-device approaches in online tools. The WebVTT specification documents the format if you want to write files directly.

The short version

Prefer a separate .srt or .vtt file over burned-in text wherever the platform accepts one, because you can fix a typo in seconds and search engines can read it.

Treat automatic transcription as a first draft and check the proper nouns specifically. Keep subtitles to two lines, at least a second on screen, broken at natural phrases and clear of the bottom edge — and if the narration was scripted, time the script instead of correcting a machine's guess at it.