Back to Blog
srt vs burned in subtitlesworkflow-opshow-to

SRT, VTT and Burned In Subtitles: When to Use Each

DubLab TeamAugust 27, 2026 13 min read

If you're localizing videos for multiple markets, you've probably run into the format question: SRT, VTT, or burned in. All three work, but they have very different tradeoffs. Pick the wrong one and you're either stuck with subtitles you can't edit, or you're re-encoding your entire video to change a single line.

This post walks through the real consequences of each choice and shows you how to decide.

SRT, VTT and Burned In Subtitles: When to Use Each

What Each Format Actually Is

Before picking, it helps to understand the mechanics.

SRT (SubRip) is the oldest subtitle format. It's plain text with no styling. A simple SRT file looks like this:

1
00:00:05,000 --> 00:00:10,000
Good morning, everyone.

2
00:00:10,500 --> 00:00:15,000
Today we're going to talk about video localization.

Each line is a sequential number, then a timecode range, then the subtitle text. It's simple enough that even a text editor can read and edit it.

VTT (WebVTT) is newer. It's similar to SRT but adds metadata, styling, positioning, and better Unicode support. A VTT file starts with WEBVTT and can include tags like <v Speaker> for speaker labels and CSS-style positioning hints. It's richer, but more complex.

Burned in (or hardcoded) subtitles are text baked directly into the video image itself during encoding. They become part of the video file. You can't separate them from the picture without re-encoding the entire video.

Platform Support: Not All Formats Are Accepted

The most obvious difference is where each format is accepted.

SRT is the oldest and most portable. YouTube accepts SRT natively. So do Vimeo, LinkedIn, TikTok, Instagram, and most video players. It's plain text with timecodes, so almost nothing can fail to read it. If you're uploading to any mainstream platform, SRT will be accepted.

VTT is newer and richer. Browsers love it because it renders natively in HTML5 video players. YouTube also accepts VTT. But some older platforms and mobile apps choke on it. If you're uploading to a platform from 2012 or a niche tool that doesn't explicitly mention WebVTT support, SRT is safer. Test with a small file first if you're unsure.

Burned in subtitles work everywhere because they're not a separate format, they're part of the image. But this universality comes at a cost you'll regret.

The rule: use SRT for maximum compatibility. Use VTT if the platform supports it and you need styling. Only burn subtitles in if the platform literally does not accept separate files.

Accessibility: Why Separate Matters

Burned in subtitles look like they solve the problem, but they break accessibility at the foundation.

A viewer who is Deaf or hard of hearing uses a screen reader to navigate video players. Burned in subtitles are pixels, not text. The screen reader sees nothing. Separate SRT or VTT files, on the other hand, are real text. Screen readers read them aloud. Users can resize, recolor, and reposition them. It's night and day.

If accessibility matters to your audience, separate files are not optional. They're foundational. And if you have international viewers, some are likely Deaf or hard of hearing.

This also applies to automated translation and transcription tools. A separate subtitle file is a data source that other systems can process. Burned pixels in a video are not. If you ever want to extract, translate, or analyze the text later, separate files are the only option.

Video platforms themselves are moving toward accessibility requirements. YouTube, for example, shows content creators their caption coverage. Lower coverage may affect recommendations.

Editing Cost: The Hidden Penalty

Here's where format choice gets expensive.

Scenario: You published a video with SRT subtitles. A week later, a viewer points out a typo in the German dub, or the translator missed a word. You fix the SRT file, upload a new version to the platform, and reupload it. Total time: five minutes.

Now imagine the same typo in burned in subtitles. You have to re-encode the entire video with a corrected subtitle track. That's a 20-minute wait on a laptop, or a few dollars in encoding fees if you use an online service. Multiply that by five mistakes across a 50-video campaign and you've spent more time and money than hiring a native speaker to proofread in the first place.

And if you're localizing into 10 languages, you've created 10 separate burned video files. Each language correction means another full re-encode. With separate SRT files, you swap a text file and move on. You have one video file and 10 SRT files.

The storage and bandwidth costs compound too. Ten burned videos at 500 MB each is 5 GB. One video plus ten SRT files is roughly 500 MB plus maybe 100 KB total. If you're hosting these files or serving them through a CDN, that's a meaningful difference in monthly costs.

SEO: Text Is Discoverable, Pixels Are Not

Google can read SRT and VTT files. It crawls them, indexes the text, and uses it as ranking signals for your video.

Burned in subtitles are pictures. Google cannot read pictures. Your video stays invisible to search queries in languages other than English.

Example: A Spanish speaker searches for "cómo localizar videos" (how to localize videos). If you burned Spanish subtitles into your video, Google finds nothing. If you uploaded a Spanish SRT file, the phrase matches and your video ranks.

This is especially powerful for tutorial content, how-to videos, and niche topics where viewers search for specific terms or phrases. A single well-crafted SRT file can unlock search traffic in 92+ languages.

Storage, File Organization, and Version Control

When you choose separate files, you also choose how to organize them.

With SRT, a typical structure is one video file plus a folder of subtitles:

video-project/
├── my-video.mp4
└── subtitles/
    ├── my-video-en.srt
    ├── my-video-es.srt
    ├── my-video-de.srt
    └── my-video-fr.srt

This structure scales. You can version the subtitles, track which have been reviewed, and easily swap a single language without touching the video.

With burned subtitles, you have:

video-project/
├── my-video-en.mp4
├── my-video-es.mp4
├── my-video-de.mp4
└── my-video-fr.mp4

Each file is independent. But updating one means re-encoding all four. And if you have 50 videos, that's 200 files instead of 50 plus a subtitles folder.

Workflow: How to Prepare and Choose

Here's a step-by-step approach to decide and implement.

Step 1: Check platform requirements. Go to each platform where you'll upload. Look for "subtitle formats supported" or "closed caption formats." Most platforms list SRT explicitly. Document what they accept. If all platforms accept SRT, move to step 2. If some require burned subtitles, you'll need to burn for those and upload SRT for the others.

Step 2: Assess your editing needs. Ask yourself: will you ever need to change the subtitles after publishing? If you're publishing tutorial videos or educational content, the answer is probably yes. If you're publishing music videos or one-off entertainment, probably no. If yes, use SRT or VTT. If no, burning is simpler initially, but you'll still regret it the first time you find a typo.

Step 3: Check accessibility requirements. Do you operate in a market with accessibility regulations? The US, UK, EU, Australia, and Canada all have requirements for caption coverage or accessibility. Even if you're not required, accessibility is a business advantage: it expands your audience and improves platform algorithms.

Step 4: Prepare the subtitle file. Get your translated text with timecodes. Use a subtitle editor like Subtitle Edit or Aegisub to timing and formatting. Export as SRT (the default). The file should be named consistently, e.g., video-title-xx.srt where xx is the language code.

Step 5: Test on one platform. Upload the SRT file to one platform, play back the video, and verify the timing and rendering. Most players render SRT identically, but occasional quirks show up. Better to catch them now than after 50 videos.

Step 6: Archive and track. Store the SRT files in version control or a shared folder with the video. Note the platform used, date, and any issues. If you ever need to update, you'll know where to find the source.

Timing and Synchronization: The Critical Detail

Subtitle timing is everything. Even the best translation fails if the subtitle appears before the line starts or after it ends.

When you dub a video, the dubbed audio is often slightly longer or shorter than the original. A Spanish translation might run longer than English because Spanish uses more syllables. If you copy the timecodes from the English subtitles directly, the Spanish subtitle will end early and the viewer hears dialogue with nothing on screen.

This is why timing is a separate step from translation. Here's the process:

  1. Translate the script and note the word count per line.
  2. Record or generate the dubbed audio.
  3. Measure the duration of each dubbed line in the audio file.
  4. Adjust the subtitle timecodes to match the dubbed audio, not the original.
  5. Test and refine.

With SRT, you adjust timecodes in a text editor or subtitle software in minutes. With burned subtitles, you have to re-encode the entire video. If you discover the timing is off after publishing, you're stuck.

Professional video editors and dubbers know this: timing is iterative. You discover issues during playback and fix them. SRT lets you fix; burning does not.

Common Mistakes and Fixes

Mistake 1: Mismatched timecodes. You have a video where the dubbed audio is slightly faster than the original, so the subtitles end before the dialogue finishes. Symptom: subtitles disappear, then the speaker keeps talking.

Fix: Use a subtitle editor like Subtitle Edit or Aegisub to adjust the timecodes. You can shift the entire track by a fixed amount (e.g., 0.5 seconds) or re-time individual lines. Playback test, then adjust again if needed. With SRT, this is a one-minute fix. With burned subtitles, you re-encode the entire video, a 20-minute process.

Mistake 2: Encoding mismatch. Your SRT file is encoded in UTF-16, but the platform expects UTF-8. Symptom: non-ASCII characters (é, ñ, ü) display as garbage or cause upload errors.

Fix: Save the SRT file as UTF-8 in your editor. Most modern text editors do this by default, but check the encoding menu if subtitles look broken. In most editors, this is "File > Save As" and select "UTF-8" from the encoding dropdown.

Mistake 3: Missing subtitle upload. You upload the video file but forget to upload the SRT. The platform doesn't auto-detect it or associate it with the video.

Fix: After uploading the video, look for a "add captions" or "upload subtitles" button. It's usually in the video settings panel or appears after the video finishes processing. Upload the SRT manually. Some platforms let you name the file with the language code (e.g., video.en.srt) and they auto-detect the language.

Mistake 4: Burned subtitles with wrong language. You burned French subtitles into the video, but the platform's auto-detect reads it as Spanish because the font and timing threw off the detection. Symptom: video is labeled in the wrong language and doesn't rank for French search queries.

Fix: Manually set the video language in platform settings. But better yet: don't burn. Use SRT with the correct language tag in the filename or metadata. Platforms respect explicit metadata over auto-detection.

Mistake 5: Hardcoded styling in burned subtitles that looks terrible. You burned white text with no background on a snowy scene. The subtitles are invisible against the background.

Fix: With SRT, the video player renders the subtitles, usually with a semi-transparent black background for contrast. The player's style engine, not your encoding, controls the look. This is actually more readable across all videos and devices. Users can also adjust subtitle appearance in player settings.

Mistake 6: Subtitle overlap or gaps. Subtitles overlap, leaving no gap between one line and the next. Or there are gaps in dialogue where no subtitle appears.

Fix: In your subtitle editor, review the timeline view to spot overlaps and gaps. Adjust the end time of one line and start time of the next so they flow without overlap. A gap of 0.1 to 0.3 seconds between lines is normal.

Common Subtitle Format Comparison

AspectSRTVTTBurned In
Editing after publishYes, instantYes, instantNo, requires re-encoding
Accessibility (screen readers)YesYesNo
SEO and search indexingYesYesNo
Platform compatibilityNearly universalMost modern platformsAll platforms
File sizeTiny (KB)Tiny (KB)Adds megabytes to video
Styling optionsNoneYes (CSS)Flexible (anything you encode)
Storage per languageOne small fileOne small fileOne entire video file
Re-encoding requiredNoNoYes, per language

Quick Decision Framework

Start with these three questions:

  1. Will you ever edit the subtitles after publishing? If yes, use SRT or VTT. If you never change anything after upload, burned is simpler initially. But consider that you might catch typos later, so "no" is rare.

  2. Does your audience include Deaf or hard of hearing viewers, or do you care about screen reader access or legal compliance? If yes, separate files are required. Burned subtitles fail completely.

  3. Do you want the text to be searchable and indexed by Google? If yes, use SRT or VTT. If the video is purely entertainment and discovery doesn't matter, burned subtitles work.

Most creators should default to SRT. It's compatible everywhere, it's text, it's searchable, and it costs nothing to fix.

Use VTT if the platform supports it and you want speaker labels or custom positioning. Burn subtitles in only when the platform literally does not accept separate files, which is rare in 2026.

What to Do Next

  1. Audit your current videos. List each video and note whether you've burned subtitles or uploaded separate files. Identify videos with mistakes or language updates you've wanted to make but couldn't without re-encoding.

  2. Check your platform documentation. Visit YouTube, Vimeo, or wherever you publish. Note which subtitle formats they accept and whether they have language detection. Bookmark this for reference.

  3. Pick a test video. Choose one video you've already published with burned subtitles. Generate an SRT file from the existing subtitles (most subtitle editors can do this if you know the timecodes). Upload it to the platform and test playback. This shows you the workflow.

  4. Set up a subtitle folder structure. Create a simple folder on your computer or cloud storage for all future subtitles. Name them consistently: video-title-language-code.srt. Store them alongside the video files.

  5. Update your workflow. For your next video dub, generate SRT files instead of burning. Upload them to your platform. Track the time and hassle saved compared to re-encoding. You'll see the value instantly.


🚀 Start Dubbing Your Videos Today

DubLab uses AI to translate your videos into 92+ languages in minutes.

📱 Download for iOS

🌐 Try Free at dublab.app