Draw your subtitles into the picture itself, so they show up everywhere — on a phone, in a social feed, on a television that has never heard of SRT files. The sound is copied across untouched.
Drag & drop a video or click to browse
MP4, MOV, AVI, MKV, WEBM and anything else ffmpeg reads — up to 500 MB, 30 minutes
Now the subtitles — click to browse
SRT, VTT, ASS or SSA. Any encoding: if it is not UTF-8 we convert it rather than failing.
Upload a video and a subtitle file, and get the video back with the subtitles drawn into the picture. The work is done with ffmpeg and libass on our server rather than in your browser, so the file can be as large as your connection can carry and the text is laid out by the same renderer a desktop video player uses.
A subtitle file sitting next to a video is the better format in every way except one: something has to load it. Upload that video to Instagram, TikTok, LinkedIn or most television apps and the subtitle file is simply not there — the words you wrote never reach anyone. Burning puts them in the picture, where nothing can fail to display them and nothing can turn them off. The trade is that they are now part of the image: you cannot switch languages, you cannot turn them off, and changing a typo means burning again from the original. Keep the original file.
Drawing text onto a frame means encoding that frame again, so this is the slowest tool we run and it cannot be made otherwise. Measured here on 2026-09-13, 30 seconds of video on four pinned cores:
| Resolution | Time for 30 s | Speed |
|---|---|---|
| 480p | 4.19 s | 7.2× faster than the video plays |
| 720p | 7.57 s | 4.0× faster |
| 1080p | 15.58 s | 1.9× faster |
So a ten-minute 1080p video takes around five minutes, and a ten-minute 720p one around two and a half. The audio is never part of that. Only the video stream goes through the subtitle filter, so the sound is copied straight across — we checked by hashing the audio out of the file that went in and the file that came out, at all three resolutions, and it matched every time. Whatever burning costs you, it cannot cost you the sound.
Subtitle files are text, and text has an encoding. Twenty years of Windows subtitle editors wrote SRT in Windows-1252, not UTF-8, and ffmpeg does not guess: hand it one and it stops with "Invalid UTF-8 in decoded subtitles text" and produces nothing at all. We reproduced exactly that on our own server. It is why a tool can look broken on a file that plays perfectly in VLC. This page reads the file itself first, tries UTF-8, then Windows-1252, then Latin-1, rewrites it as UTF-8, and tells you which one it turned out to be — so an accented French or Portuguese subtitle written in 2009 burns in correctly instead of failing.
Left alone, libass draws subtitles at about 5.4% of the frame height with a 3.1% bottom margin — small, and hard against the bottom edge, which is exactly where a phone puts its own controls and a television puts its overlay. The default here is larger and sits further in: measured at 9.2% of frame height, and identically so at 480p, 720p and 1080p, because the size is set in the subtitle format's own coordinate space rather than in pixels. One setting, the same result whatever you upload. The shaded band behind the text is the default for the same reason: an outline alone disappears over a white shirt or a bright sky.
We tested Latin, Cyrillic, Greek, Hebrew, Arabic, Japanese, Korean, Thai and Devanagari against the fonts on the server, and every one came back as real glyphs rather than the empty boxes that mean a missing font — Arabic shaped and laid out right-to-left, Japanese and Korean fully covered. Where one font runs out of characters, the renderer falls through to another that has them, per glyph. Long lines wrap on their own rather than running off the edge.
Free use is two minutes of video a day, from files up to 100 MB. A credit pack raises that to 500 MB per file and 30 minutes of video. That 30 minutes is lower than our other video tools allow, and deliberately: at 1.9× realtime a 30-minute 1080p video is already a quarter of an hour of solid work, and one job at a time gets the machine. Your uploads are deleted as soon as the burn finishes, and the finished video six hours later.
Because most places a video ends up will not load a separate file. Instagram, TikTok, X, LinkedIn, WhatsApp, most television apps and most people's media players either ignore an SRT sitting beside the video or never receive it in the first place. Burned subtitles are part of the picture, so they display everywhere, including on mute — which is how most social video is watched. The cost is that they are permanent: no switching languages, no turning them off, and a typo means burning again from the original. So keep your original video and your subtitle file; burn a copy.
The picture is re-encoded, so strictly yes, a little — there is no way around it, because putting text into an image means writing that image again. We encode at a quality setting where the loss is not visible on normal footage. The sound is a different story and worth being precise about: it is never touched. Only the video stream goes through the filter, so the audio is copied across as-is, and we verified that by hashing the audio out of both files at three resolutions. It matched every time.
Almost certainly its encoding. A subtitle file is plain text, and text written by older Windows subtitle software is usually Windows-1252 rather than UTF-8. ffmpeg refuses those outright — it stops with "Invalid UTF-8 in decoded subtitles text" and writes no file — which is why a subtitle that plays perfectly in VLC can be rejected by an online burner. This page reads the file itself before ffmpeg sees it, works out the encoding, rewrites it as UTF-8 and tells you which one it was. If your accented characters were coming out as gibberish elsewhere, this is why.
Yes for every script we tested: Latin, Cyrillic, Greek, Hebrew, Arabic, Japanese, Korean, Thai and Devanagari all came back as real glyphs, not the empty boxes that mean the font has no character for them. Arabic and Hebrew are shaped and laid out right-to-left properly. Where one font does not cover a character the renderer falls through to another that does, character by character, so a mixed-language subtitle works too. Very long lines wrap by themselves rather than running off the side of the frame.
Three sizes, white or yellow, a shaded band or a plain outline, and top or bottom. That is deliberately a short list — it covers what people actually change, and every combination has been checked at three resolutions so none of them can come out unreadable. If you want full control, make an ASS or SSA file in a subtitle editor and upload that instead: we detect it, use its own styling exactly as written, and ignore the options on this page. Overriding the styling in an ASS file would throw away the only reason to have made one.
Video: anything ffmpeg reads — MP4, MOV, AVI, MKV, WEBM, FLV, WMV and what phones, cameras and screen recorders produce. Subtitles: SRT, VTT, ASS or SSA, in any text encoding. You get back an MP4, which is the format that plays on the most things, with the picture re-encoded and the audio copied. A video with no audio track is fine; it comes back with no audio track.
Faster than the video plays, but not by much at high resolution. Measured on four pinned cores: 7.2× realtime at 480p, 4.0× at 720p and 1.9× at 1080p — so a ten-minute 1080p video takes about five minutes of work, plus the upload. The page shows an estimate as soon as the server has read your file and knows its resolution, and a progress bar that follows the encoder rather than a timer. Uploading a 1080p file is often the slower half.
Both uploads are deleted as soon as the burn finishes, and the finished video six hours later. That window exists only so the download link still works if you close the tab and come back to it. Nothing is kept after that, nothing is read, and nothing is handed to anyone — which for a subtitle file is worth saying plainly, since subtitles are the part of a video that spells out exactly what is in it.