Subtitle Tools — Convert SRT/VTT & Burn Subtitles Online Free

Convert subtitle files between SubRip (.srt) and WebVTT (.vtt) with line-by-line syntax validation, or hardcode subtitles directly into your MP4 videos. 100% client-side — your files never leave your device.

Offline-ready · 0 B uploaded

Input Subtitles

Geek check: open DevTools → Network tab — 0 bytes of your data uploaded.

SRT vs. WebVTT: Two Standards for Captions

Subtitles are essential for accessibility, international audiences, and social media viewers who watch videos on mute. The two dominant caption formats across the internet are SubRip (.srt) and WebVTT (.vtt):

  • SubRip (.srt): The historic standard created for DVD ripping. It relies on sequential integer counters, comma millisecond separators (00:01:23,456), and clean multi-line text blocks. It is supported by nearly every video player (VLC, QuickTime, Premiere, DaVinci Resolve).
  • WebVTT (.vtt): Developed by the W3C for native HTML5 <video> elements. It begins with a mandatory WEBVTT header, uses dot millisecond separators (00:01:23.456), and supports rich cue styling (such as alignment, vertical margins, and speaker voice tags).

Our converter verifies your subtitle format with line-numbered error reports. If a timestamp is missing a zero, has minutes above 59, or contains start times after end times, you will immediately see the exact line number and expected syntax to fix.

Hardcoding Subtitles for Social Media and Mobile Playback

While soft subtitles allow viewers to switch languages or toggle captions off, they have a major downside: many social platforms (Instagram Reels, TikTok, YouTube Shorts, X/Twitter, WeChat Channels) discard soft subtitle tracks during video upload. Burning (hardcoding) renders text directly into the video stream, guaranteeing your subtitles will always be legible on any screen, regardless of whether the player supports subtitle tracks.

Frequently Asked Questions

What is the difference between SRT and WebVTT subtitles?

SRT (SubRip) is the traditional and most widely supported subtitle format for desktop video players and editing software; it uses comma separators for milliseconds (00:00:01,000) and sequential numbering. WebVTT (Web Video Text Tracks) is the modern HTML5 standard for web video (<track> tag); it starts with a 'WEBVTT' header, uses dot separators for milliseconds (00:00:01.000), and supports CSS styling, voice tags, and layout positioning.

Why should I burn (hardcode) subtitles instead of using soft subtitles?

Soft subtitles exist as separate text tracks that players can toggle on and off. However, popular social media platforms (such as TikTok, Instagram Reels, YouTube Shorts, and X/Twitter) or certain smart TVs often ignore, misrender, or strip external subtitle tracks. Hardcoding (burning) permanently draws the subtitle text into the video frames, guaranteeing that your text displays with exact fonts, size, and timing on every device and platform.

How does in-browser font rendering work for burning subtitles?

Our tool runs a WebAssembly build of FFmpeg directly inside your web browser. When you start the burn process, it dynamically loads a standard OpenType/TrueType font (DejaVu Sans) into the virtual filesystem along with an automated Fontconfig profile. FFmpeg's libass filter uses this font to render clean, anti-aliased subtitles into each video frame without needing native software installed on your machine.

Are my video files or subtitle tracks uploaded to your server?

No. Everything—from parsing and converting SRT/VTT text to re-encoding the full video with burned-in subtitles—runs 100% locally in your browser through WebAssembly and HTML5 file APIs. Zero bytes of your video or subtitle data are ever uploaded or transmitted across the internet.

Why does burning subtitles take longer than converting text?

Converting between SRT and WebVTT is purely text transformation and executes in milliseconds. In contrast, burning subtitles requires decoding each video frame, drawing vector glyphs onto the frame at your specified font size and margin, and re-encoding with H.264 video compression. Because your browser's WebAssembly sandbox uses a subset of CPU threads, encoding a 1-minute video typically takes between 30 to 90 seconds depending on your computer's speed.