How to Burn Subtitles Into a Video (Without Uploading It Anywhere)
Burn subtitles into a video on your own machine: the four methods compared, the FFmpeg commands that work, and how to avoid the quality loss re-encoding causes.
Burning subtitles into a video means drawing the text into the picture and re-encoding, so the captions travel with the file as pixels. You need it for TikTok, Reels and Shorts, which accept no subtitle files at all, and any time the captions are part of the design rather than an accessibility option.
You do not need to upload anything to do it. FFmpeg does it in one command, HandBrake and Subtitle Edit do it from a window, and a desktop subtitle app such as Sablate also makes the subtitles first. All of them run on your own computer, with no file-size cap and no wait for an upload.
This covers when an online tool is still the right choice, the four ways to burn subtitles in, how to do it without the command line, what changes with long recordings, and the two things that actually damage quality.
Online tool or offline: which should you use?
Most searches for this land on a browser editor first, and for a short clip that is fine. The difference shows up with length, file size and privacy.
| Online editor | Offline (FFmpeg, HandBrake, desktop app) | |
|---|---|---|
| Your video is uploaded | Yes, the whole file | No |
| File size | Capped per plan | Limited only by your disk |
| Long recordings | Upload time grows with length | Only the encode takes time |
| Confidential footage | Leaves your machine | Stays on it |
| Install needed | No | Yes |
| Makes the subtitles too | Usually | Desktop apps yes, FFmpeg and HandBrake no |
The caps are real, and they are low on free plans. Kapwing's storage policy, for example, allows 250 MB per file on its free plan and 6 GB on paid ones. At a typical 1080p bitrate of around 8 Mbps, 250 MB holds a little over four minutes of video.
So use an online editor when the clip is short, nothing in it is confidential, and you cannot install software on the machine in front of you. For anything longer than a few minutes, for client or internal footage, and for a batch of files, burn in locally. The offline subtitle generator comparison covers the desktop apps that also create the subtitles.
When burn-in is the right call
| Burned in (hardsub) | Subtitle file or track (softsub) | |
|---|---|---|
| Viewer can turn it off | No | Yes |
| Works on TikTok, Reels, Shorts | Yes | No, not supported |
| Works on YouTube, Vimeo | Yes | Yes, and searchable |
| Counts for accessibility compliance | Usually not | Yes |
| Indexed by search engines | No | Yes |
| Fix a typo later | Re-render the video | Edit a text file |
| Multiple languages in one file | No, one render each | Yes, one track each |
| Styling preserved exactly | Yes | Only in ASS tracks |
The practical answer for most people is both: burn in for vertical social platforms where nothing else works, and ship a subtitle file everywhere that reads one, because a file is searchable, switchable and correctable. If you want both from one job, multi-language delivery covers how the two outputs come from the same timeline.
The four ways to burn subtitles in
| FFmpeg | HandBrake | Browser tools | Desktop subtitle apps | |
|---|---|---|---|---|
| Price | Free | Free | Free tier, then subscription | One-time or subscription |
| Uploads your video | No | No | Yes, the whole file | No |
| File size / length limit | None | None | Yes, usually strict | None |
| Creates the subtitles | No | No | Yes | Yes |
| Styling control | Through ASS or force_style | Limited | Templates | Full, with live preview |
| Learning curve | Command line | Moderate | None | Low |
Two honest notes. FFmpeg and HandBrake are free and excellent at this, and if you already have a finished subtitle file, FFmpeg is a single command — there is no reason to buy anything. What neither of them does is produce the subtitles: they burn in a file you already have, timed and corrected elsewhere. Browser tools do produce them, but the upload is not optional, which rules them out for confidential material and for anything longer than their cap.
Burning in with FFmpeg
For a plain SRT:
ffmpeg -i input.mp4 -vf "subtitles=subs.srt" -c:a copy output.mp4
For a styled ASS file, use the ass filter so the styling is honoured rather than flattened:
ffmpeg -i input.mp4 -vf "ass=subs.ass" -c:a copy output.mp4
To control quality explicitly rather than accepting the default:
ffmpeg -i input.mp4 -vf "subtitles=subs.srt" \
-c:v libx264 -crf 18 -preset slow -c:a copy output.mp4
To restyle an SRT without converting it first:
ffmpeg -i input.mp4 \
-vf "subtitles=subs.srt:force_style='FontName=Arial,FontSize=24,Outline=2'" \
-c:a copy output.mp4
The Windows trap. The path inside the filter is parsed by the filter, not the shell, so a drive letter's colon and the backslashes have to be escaped. This is the single most common reason the command fails with a file-not-found error on a file that plainly exists:
ffmpeg -i input.mp4 -vf "subtitles='C\:/Videos/subs.srt'" -c:a copy output.mp4
Keep the subtitle file in the working directory and pass a bare filename whenever you can — it avoids the problem entirely.
Burning subtitles in without the command line
If a terminal is not your thing, three kinds of tool do the same job from a window. The first two are free and burn in a subtitle file you already have; the third also makes the file.
HandBrake
HandBrake is a free video converter for Windows, Mac and Linux. Open the video, go to the Subtitles tab, use Tracks to add your external SRT, set that track to burn into the video, and start the encode. Two limits are worth knowing: HandBrake's documentation notes that an MP4 can take only one burned-in track, and the styling is limited to what a plain SRT carries.
Subtitle Edit
Subtitle Edit, the free subtitle editor, has a burned-in export in its Video menu that runs FFmpeg for you, and offers to download FFmpeg if it is missing. It is the natural choice when you are already correcting the timing there.
A desktop subtitle app
If you do not have a corrected subtitle file yet, the burn-in is the last step of a longer job: transcribe, correct, style, render. Sablate does that end to end on your own machine — transcription with Whisper locally, an editor with timeline retiming and reading-speed warnings, 13 caption presets, and a burn-in that matches the preview. If you edit in DaVinci Resolve, the free version can import an SRT and burn it in at export instead.
Burn-in is available on the free plan with a small corner mark, for videos up to 10 minutes. Pro removes the mark and the length limit and adds .ass, multi-track .mkv and batch export, for a single $29 payment. Download it or read the pricing page for the full split.
Burning subtitles into long or large videos
Length changes two things: getting the file to the tool, and the encode itself.
The upload. A two-hour 1080p recording at around 8 Mbps is about 7 GB. On a 20 Mbps upload connection that is close to 50 minutes before an online tool can even start, and the finished file has to come back down. Burning in locally skips that step entirely.
The encode. Burning in re-encodes every frame, so a two-hour file takes a while on any machine. Before committing to the full encode, render the first minute and check the font, size and position there rather than after an hour of waiting:
ffmpeg -i input.mp4 -t 60 -vf "subtitles=subs.srt" -c:v libx264 -crf 18 -preset slow -c:a copy test.mp4
Speed versus size. -preset medium is noticeably faster than slow and produces a slightly larger file at the same CRF. A hardware encoder (h264_nvenc on NVIDIA cards, h264_videotoolbox on a Mac) is faster still, but needs a higher bitrate for the same visual quality. Keep -c:a copy either way: re-encoding the audio of a long file costs time and a second generation of loss for nothing.
Sablate has no length limit on Pro, and the render runs locally with a progress bar and a cancel button, so a feature-length recording is a matter of waiting, not of splitting the file into pieces.
What actually costs you quality
Two things, and neither is the burn-in itself.
Re-encoding an already-compressed file. Burning in requires a re-encode, which is lossy. Doing it to your master costs almost nothing visible. Doing it to a file that a platform already compressed means compressing compression artefacts, and that is where blocking and mush appear. Always start from the highest-quality version you have, and never burn captions into a file that has already been burned once.
Accepting the default encoder settings. -crf 18 with x264 is visually near-transparent for most content; the default of 23 is noticeably softer on detailed footage. -preset slow buys a smaller file at the same quality in exchange for time. And -c:a copy leaves the audio stream untouched — there is no reason to re-encode audio when you are only changing the picture.
Why the render does not match the preview
Two causes, both fixable before you spend an encode.
Fonts. A renderer draws with the font it can find. If the font you picked is not installed, or cannot draw the script — most display caption faces cover Latin, Cyrillic and Greek and nothing else — a substitute is used, and Arabic, Thai, Hangul or CJK text can come out as empty boxes. Check the font before rendering twelve languages, not after.
Canvas size. ASS positions and font sizes are relative to a virtual canvas declared in the file, not to the video's pixel dimensions. The same font size produces different on-screen text on a 1080p and a 4K source unless the canvas is pinned. Sablate pins the caption canvas to a 1080-high virtual frame and derives the width from the source's real aspect ratio, including rotation metadata, so a font size means the same thing regardless of what resolution you shot at — and the editor preview scales against exactly the same canvas the renderer uses.
This is also why burn-in quality differs so much between tools. Many online editors composite captions as a flat text overlay; the burn-in in Sablate is rendered by libass, the same engine media players use for ASS subtitles, so outlines, shadows, per-word karaoke timing and script-correct fonts come out as real subtitle typography rather than approximated graphics.
Vertical and square output
If the video is going to Reels, Shorts or TikTok, convert the aspect ratio during the render rather than cropping afterwards. Cropping a finished 16:9 burn-in to 9:16 cuts the sides off the captions along with the picture.
Sablate renders at 16:9 (1920×1080), 9:16 (1080×1920) or 1:1 (1080×1080), either cropping to the target frame or padding it with a blurred copy of the source, and lays the captions out for the final frame. Keep captions above the bottom third of a vertical frame: Meta's guidance for Reels keeps the bottom 35 percent clear, because the platform's own text and buttons cover it. Where to put subtitles on Reels, TikTok and Shorts has each platform's safe zone.
The short version
Use an online editor only for short clips with nothing confidential in them; burn in locally for everything else, because there is no upload, no size cap and no length cap. Burn in when the platform reads no subtitle file, or when the captions are part of the look — and ship a subtitle file everywhere else, because text you can edit beats pixels you cannot. Render from your master, not from an upload copy. Use CRF 18 and copy the audio. Test the first minute of a long file before the full encode. And check the font and the canvas before you spend that encode, because those are the two things that make a perfect subtitle file come out wrong.
Frequently asked questions
What does burning subtitles into a video actually do?
It draws the text into the picture itself and re-encodes the video, so the captions become pixels rather than a separate track. Nobody can switch them off, no player needs to support a subtitle format, and platforms that ignore subtitle files show them correctly. The trade-off is that it is permanent and it costs one re-encode.
Does burning in subtitles reduce video quality?
It re-encodes the video, so some loss is unavoidable, but it can be made invisible. Encode from your highest-quality master rather than an already-compressed export, use a quality-targeted setting such as CRF 18 with x264, and copy the audio stream instead of re-encoding it. Burning the same file twice is what visibly degrades it.
Can I burn subtitles in without uploading my video?
Yes. FFmpeg, HandBrake and desktop subtitle applications all run entirely on your own machine, with no upload and no file-size limit. Browser-based tools have to upload the whole video to a server first, which is why they cap file size and length, and why a two-hour recording usually fails on them.
What is the FFmpeg command to burn subtitles into a video?
For a plain SRT: ffmpeg -i input.mp4 -vf subtitles=subs.srt -c:a copy output.mp4. For a styled ASS file, use the ass filter instead of subtitles. On Windows the path inside the filter needs escaping, which is the most common reason the command fails with a file-not-found error.
Why do my burned-in subtitles look different from the preview?
Usually fonts or canvas size. The renderer substitutes a different font if the one you chose is missing or cannot draw that script, and font sizes are relative to a virtual canvas, so the same number produces different text sizes on a 1080p and a 4K source. Preview and render have to use the same font and the same canvas to agree.
Do I need to burn in subtitles for TikTok, Reels and Shorts?
Yes. None of those platforms accepts a subtitle file alongside an upload, so captions there are either burned into the video or generated by the platform itself. Platform-generated captions are free but styled by the platform and often wrong on names and jargon, which is why most creators burn their own in.
How do I burn subtitles into a long video?
Do it locally. A two-hour 1080p recording is several gigabytes, more than most browser tools accept and an hour or so of uploading on a typical connection. FFmpeg, HandBrake or a desktop app re-encode it on your own machine. Render the first minute as a test before committing to the full encode, and keep the audio copied rather than re-encoded.