How to burn subtitles into a video with free tools

To burn subtitles into video you need a subtitle file and a tool that redraws the picture with the text on it. HandBrake does that through a window, ffmpeg in one command, and both are free and run on your own machine. The result plays anywhere, with nothing for the viewer to switch on. The catch is that it is permanent. Three ways to add subtitles without uploading covers the alternatives; this post stays on burning in.

Burned-in subtitles become part of the picture

Burned-in, hardcoded, hardsubs, open captions: all the same thing. The words are drawn into the frames, so they are pixels, not text.

HandBrake’s documentation defines its two kinds of output in a line each. Hard Burn means “the subtitles are written on top of the image permanently. They cannot be turned on or off like on the DVD.” Soft subtitles “appear as separate selectable tracks in your output file”, which the viewer can switch on and off. One more line settles it for some people: soft subtitles are currently unsupported in the WebM container. If the output has to be WebM, burning in is the only route HandBrake documents.

The trade-off runs one way. A caption file can be edited, restyled or thrown away, and the video underneath is untouched. Once the text is in the frames, the only way back is encoding again from the original. Keep the original video and the subtitle file, always.

The second cost is easy to miss. Burned-in text cannot be switched off or resized, and a screen reader has nothing to read, because there is no text there to read. It is not accessible the way a caption file is. If you are burning in to meet an accessibility requirement, read what WCAG actually requires first, and supply a caption file as well wherever you can.

Burn subtitles into video when nothing else will carry them

Most of the time you should not burn in. Do it when one of these is true.

• The destination has no caption upload at all. Check its help page first; many do accept SRT, and uploading the file is the better option when it exists.
• The video will autoplay with the sound off. Chrome’s autoplay policy is blunt: “Muted autoplay is always allowed.” A video playing silently in a feed shows nothing but the picture, so anything you want read has to be in the picture.
• The file has to travel on its own, as a download or on a USB stick, and you cannot predict the player.

Get the subtitle file right before you encode, because a typo spotted afterwards means encoding the whole video again. If you have no SRT yet, drop the video on our transcriber and export .srt; it runs on your graphics card in desktop Chrome or Edge, English only, and nothing is uploaded. Read it through, then check the sync: timing drift is cheaper to fix now than after an hour of encoding.

The HandBrake route, step by step

HandBrake is a free, open-source transcoder for Windows, Mac and Linux. These steps are from its documentation.

1. Open the video. HandBrake presents the Open Source dialog on launch, and it is also on the toolbar. You can drag a file onto the main window instead.
2. Choose a preset. For a computer rather than a listed device, HandBrake’s documentation calls the default Fast 1080p30 preset “a good choice”, compatible across a wide range of software and devices.
3. Go to the Subtitles tab and press the Tracks button, then pick your option. A new track appears that you can configure. HandBrake reads SRT from the source file, or you import a separate file through the Subtitles tab.
4. Set the Char Code dropdown. The documentation warns that the wrong code “will result in your output file having no subtitle track, and can cause the player to crash when playing that track”. UTF-8 is the usual answer for a browser export.
5. Tick Burn In for that track. If the cues are early or late by a fixed amount, the same tab takes an offset in milliseconds; HandBrake suggests trial and error on a single chapter to find the value.
6. Check it with Preview, which encodes a short piece from a start position and duration you set, via Live Preview.
7. Set the Destination, the Save As name and the folder, then press Start on the toolbar.

One limit shapes the job. HandBrake’s defaults documentation states that it can burn in 1 subtitle track to an encoded file. Its subtitles page repeats that for MP4 output, and says MKV can pass several tracks through but still burn only one.

The ffmpeg route is one command with the subtitles filter

ffmpeg’s subtitles filter, in the project’s own words, draws “subtitles on top of input video using the libass library”. It needs a build configured with --enable-libass, and converts the file you pass it to ASS format internally before drawing it.

The whole job is one line:

ffmpeg -i input.mp4 -vf subtitles=subs.srt -c:v libx264 -crf 20 -c:a copy output.mp4

-vf is ffmpeg’s documented alias for -filter:v, which attaches a simple filtergraph to the video stream. subtitles=subs.srt is the documented short form; the filter docs give subtitles=sub.srt as their first example and note it is equivalent to subtitles=filename=sub.srt. The audio is not drawn on, so -c:a copy hands it through untouched: copy is the documented value telling ffmpeg that “the stream is not to be re-encoded”.

The same filter reads subtitles already inside a container: the documentation gives subtitles=video.mkv for that file’s default subtitle stream and subtitles=video.mkv:si=1 for the second one.

What each route costs you

Styling and quality are both decided when you burn

An SRT carries no styling. It is an index, two timestamps and a line or two of text, which is why every player reads it. The look comes from whatever burns the subtitles in.

With ffmpeg, the documented control is force_style, which overrides “default style or script info parameters of the subtitles” and “accepts a string containing ASS style format KEY=VALUE couples separated by ‘,’”. The documentation’s own example puts the text in 80% transparent blue DejaVu Serif:

ffmpeg -i input.mp4 -vf "subtitles=subs.srt:force_style='Fontname=DejaVu Serif,PrimaryColour=&HCCFF0000'" -c:a copy output.mp4

The documentation does not list the available style keys, since they are ASS names rather than ffmpeg’s own, so try anything beyond its example on a ten-second clip first.

HandBrake documents no styling control for burned-in SRT. It does document that SSA subtitles burn in with “all styling (e.g. fonts, colors, etc)” preserved, while animated effects such as fades and karaoke are not currently supported. If the look matters and you want to stay in HandBrake, style the subtitles in a subtitle editor, save SSA, and burn that in.

Quality is the other thing you are choosing here, because drawing on the frames means decoding and re-encoding the video. HandBrake’s advice is to “always use constant quality unless you have a specific reason not to”, and it publishes starting ranges for the x264 and x265 encoders: RF 18 to 22 for standard definition, RF 19 to 23 for 720p, RF 20 to 24 for 1080p, RF 22 to 28 for 4K. Lower numbers mean higher quality and bigger files, and drastically lower settings, HandBrake warns, may show significant loss of detail, which matters for small subtitle text.

The -crf 20 above is the same control on the same encoder. ffmpeg’s documentation describes libx264’s crf only as setting the quality for constant quality mode, with no recommended range, so HandBrake’s numbers are a sensible place to start.

Get the text right, then burn it in once. If you still need the subtitle file, transcribe the video in your browser and export SRT before you open HandBrake.

Frequently asked questions

Can I remove burned-in subtitles later? No. HandBrake’s documentation is explicit that hard-burned subtitles are written on top of the image permanently and cannot be turned on or off. The only route back is encoding again from the original, which is why you keep it.

Do burned-in subtitles count as accessible captions? Not the way a caption file does. They cannot be switched off or resized, and there is no text for a screen reader or a search index to read. Supply a caption file wherever the destination accepts one, and see what WCAG actually requires before relying on burned-in text alone.

Can I burn in two languages at once? HandBrake documents one burned-in subtitle track per encoded file, and repeats that limit for MP4. For two languages, make two files.

Will the subtitles survive being uploaded and re-compressed? They stay in the picture, since they are part of it. Small text can soften when a platform re-encodes a video, and HandBrake’s quality page warns that drastically lower settings show significant loss of detail, so do not set the text tiny.

Sources, checked 15 September 2026

• HandBrake Documentation, “Subtitles”, Hard Burn and soft subtitles, SRT import, Char Code, offset, WebM and MP4 limits: https://handbrake.fr/docs/en/latest/advanced/subtitles.html
• HandBrake Documentation, “Audio and subtitle defaults”, one burned-in track per encoded file: https://handbrake.fr/docs/en/latest/advanced/audio-subtitle-defaults.html
• HandBrake Documentation, “Opening a video source”, Open Source dialog and drag and drop: https://handbrake.fr/docs/en/latest/workflow/open-video-source.html
• HandBrake Documentation, “Selecting a preset”, Fast 1080p30: https://handbrake.fr/docs/en/latest/workflow/select-preset.html
• HandBrake Documentation, “Adjusting quality”, constant quality and RF ranges: https://handbrake.fr/docs/en/latest/workflow/adjust-quality.html
• HandBrake Documentation, “Previewing your settings”, Live Preview: https://handbrake.fr/docs/en/latest/workflow/preview-settings.html
• HandBrake Documentation, “Starting encoding”, Destination and Start: https://handbrake.fr/docs/en/latest/workflow/start-encoding.html
• FFmpeg Filters Documentation, section 11.247 “subtitles”, options and examples including force_style: https://ffmpeg.org/ffmpeg-filters.html#subtitles-1
• FFmpeg Documentation, simple filtergraphs and the -vf alias, and the copy codec value: https://ffmpeg.org/ffmpeg.html
• FFmpeg Codecs Documentation, libx264 crf option: https://ffmpeg.org/ffmpeg-codecs.html
• Chrome for Developers, “Autoplay policy changes”, muted autoplay: https://developer.chrome.com/blog/autoplay/