Guide · Audio & Video
Burn-In Subtitles from SRT: Limits and Workflow
Updated 2026-10-23 · 4 min read
Reviewers who refuse to load sidecar files, social apps that ignore .srt, and execs who open MP4 in email preview - all push the same workaround: burn subtitles into the frame. ToolComb's Video Add Subtitles does that with FFmpeg.wasm in the browser: video + SRT → new MP4 with captions baked in. No upload queue. Same ~100 MB video ceiling and ~25 MB first FFmpeg load as the rest of the cluster.
Burn-in is a delivery hack, not the accessibility ideal. This guide covers when to use it, workflow order, limits (font, timing, line length), and privacy/rights you still carry.
Sidecar vs burn-in
Sidecar SRT/VTT: player toggles captions, users can restyle (within app), better for WCAG when the player is good.
Burn-in (hardcode): captions are part of the image. They survive re-upload to TikTok, LinkedIn native video, and "just email me the MP4." They cannot be turned off; translation means re-render; small text fails on phones if you chose tiny fonts.
Pick burn-in when the player is bad or unknown. Keep sidecar masters for YouTube/Vimeo where caption tracks work.
Workflow order
1. Finalize picture cut. Open Video Trimmer. Remove pre-roll and retakes. Subtitle timecodes must match this timeline.
2. Fix SRT timing offline if needed. Browser burn-in assumes your SRT matches the trimmed video. Drift from frame-rate mismatch or partial speed ramps needs fix in a caption editor first - WASM will not guess.
3. Open Video Add Subtitles. Load trimmed MP4 (under ~100 MB). Attach SRT.
4. Set style - font size, color, outline, margin. Preview on phone width. What reads on a 27" monitor vanishes on Instagram.
5. Export and download. New filename (demo-burned.mp4). Keep sidecar + clean video archived.
6. Optional audio pass. Bad room tone after caption review? Video Replace Audio - see Mute/replace safely.
Never trim after burn-in without re-burning - captions will slide off speech.
SRT limits the browser tool inherits
SRT is simple text + timecodes. Limits show up in practice:
- Line length: long lines wrap or clip safe areas. Break cues in the SRT (two lines max per cue is a common broadcast habit).
- Reading speed: 140–180 wpm upper bound for accessibility; faster dialogue needs editing, not smaller font.
- Special characters: UTF-8 usually fine; odd BOM or Mac line endings may confuse parsers - normalize in a text editor.
- Position tags: advanced ASS/SSA features may not map 1:1; plain SRT is the safe input.
- Multiple languages: one burn per language unless the tool merges tracks - plan separate exports.
FFmpeg draws what you give it. It will not auto-transcribe missing captions.
FFmpeg.wasm practical limits
First visit: ~25 MB engine download, compile, cache. Not your video.
Video size: ~100 MB validator cap. A ten-minute 1080p screen recording often fits; raw camera logs may not.
Encode time: subtitle filter + re-encode video is heavier than trim alone. Laptops finish reasonable; phones may struggle on long HD.
Codec: stick to H.264/AAC-friendly MP4 inputs when possible. Exotic inputs may need HandBrake pre-pass.
Privacy and confidential review
Burn-in for legal, HR, or unreleased product video is exactly when local helps: reviewers get one file, you skip parking sensitive footage on a random subtitle SaaS. Narrow claim: no ToolComb server copy for the burn step. You still loaded a web page; use policy-approved machines; close the tab after download.
Copyright and client deliverables
You may burn captions you created or licensed for video you may distribute. Burning fan subs on commercial film is still infringement. Client work: contract may require accessible sidecar delivery, not only burn-in - ask before shipping hardcoded only.
Accessibility honesty
Burn-in fails user preference (size, color, font) unless you render multiple files. For public web video with a decent player, prefer VTT + player. Use ToolComb burn-in for "they will only open MP4" stakeholders, then keep accessible assets in the archive.
Related reading
Full tool map: Best free browser audio and video tools. Soundtrack fixes after picture lock: Mute and replace audio track safely.
QA checklist before you send the burned MP4
- Play on mute - do captions carry meaning without audio?
- Play on phone portrait - bottom captions clear the home indicator area?
- Scrub to fast dialogue - cues keep up without overlapping?
- Check color blindness - yellow on white fails; use outline/shadow.
- Compare one cue against the SRT source timecode at 00:05:00 and near the end.
Stakeholders who only watch burned files will not report "VTT track missing." They will say "typo at minute four." Fix SRT, re-burn once, version the filename (v2-burned.mp4).
When not to burn
- YouTube/Vimeo with good caption upload
- Internal players that accept VTT
- Accessibility-first public sites where user font scaling matters
- Localization pipelines that swap language per locale
Burn for MP4-in-email and social native upload pain, not as default for every project.
Trim first, validate SRT against the final cut, burn with phone-readable type, keep sidecar masters, download once, test in the worst player your audience uses.
Frequently asked questions
What does burn-in mean for SRT?
Subtitles are drawn into each video frame (hardcoded). Viewers cannot toggle them off or restyle them in the player. Sidecar SRT stays separate; burn-in is pixels.
Does ToolComb upload video and SRT to burn captions?
No. FFmpeg.wasm renders subtitles locally and exports a new video file. Your media is not sent to a server for this step.
Why trim before adding subtitles?
If you cut the video after burn-in, captions drift or clip. Trim on Video Trimmer first, then burn SRT matched to the final timeline.
Will burned captions meet WCAG?
Not automatically. Contrast, size, and timing must be chosen deliberately. Burn-in is often worse for accessibility than a good player + sidecar. Use burn-in when delivery demands it.
File size limit?
About 100 MB video upload on shared validators, plus the SRT as text. Long 1080p sources may need desktop prep or lower resolution first.
Can I burn subtitles on content I do not own?
You need rights to the video and permission to create/distribute derivative captions. Local encode does not bypass copyright or platform terms.
Related guides
More reading that links back to the same tools and workflows.
Best Free Browser Audio and Video Tools (FFmpeg.wasm)
Trim, join, compress, GIF, MP3, subtitles, and waveform exports without uploading media. How ToolComb's FFmpeg.wasm tools map to real chores - and where ~100 MB and first-load limits apply.
6 min read
Mute and Replace Audio Track Safely (Browser)
Swap narration, add licensed music, or strip room tone with FFmpeg.wasm locally. Sync, ~100 MB per file, first-load engine, and copyright you still owe.
4 min read
How to Trim and Compress Video Without Uploading
Cut screen recordings and shrink MP4 for Slack, LMS, and email caps using FFmpeg.wasm locally. CRF vs bitrate, ~100 MB limits, and resize when needed.
4 min read
How to Trim Audio in the Browser (No Upload)
Cut podcast cold opens, song intros, and interview segments with FFmpeg.wasm. First-load size, ~100 MB limits, and when to join or strip silence next.
4 min read