Where Captions Go: Positioning in WebVTT, and Why SRT Cannot

Captions get covered. The comment count sits on top of the last line, the progress bar eats the bottom of the frame, or the platform draws its own caption bar right where yours already is. Everyone who publishes vertical video runs into it, and the usual advice is to move the captions up.

Which raises a question worth answering before you spend an afternoon on it: can your subtitle file say where a caption goes at all? For SRT, the answer is no. For WebVTT, yes. That difference decides what you can fix in the file and what you have to fix somewhere else.

SRT has no way to say where

An SRT cue is a number, a line with two timestamps, and the text. That is the whole format. There is no field for horizontal position, no field for vertical position, and no field for alignment. A player reading an SRT file decides placement entirely on its own, usually centered near the bottom, and the file has no say in it.

So when captions from an SRT file land under the interface, the file is not the problem and editing it will not help. The placement was never yours.

WebVTT carries positioning on the timestamp line

WebVTT puts optional settings after the timestamps, on the same line:

WEBVTT

00:00:01.000 --> 00:00:03.000 line:10% position:50% align:center
This cue sits near the top.

00:00:03.000 --> 00:00:05.000 line:90%
This one sits near the bottom.

The settings are named values. line controls how far down the cue sits, position controls how far across, align controls how the text sits within its box, size controls how wide that box is, and vertical switches to vertical writing for languages that need it. A cue with no settings falls back to the player default, so you can position two cues and leave the rest alone.

This is the part that matters for the covered-caption problem. If your player reads WebVTT, you can lift the cues that clash with the interface and leave everything else where it is.

Converting to SRT throws the positioning away

Since SRT has nowhere to put those settings, converting a positioned WebVTT file to SRT drops them. Not reformats them, drops them. Our VTT to SRT converter says so rather than doing it silently, and reports how many cues it affected:

Removed cue settings from 2 timestamp lines
because SRT does not support WebVTT positioning.

Converting back does not bring them back. The information is gone from the file, so an SRT to VTT conversion produces cues with no settings and the player returns to its own default placement. If you have positioned a file and you care about that work, the WebVTT version is the master copy. Keep it.

What to do when the platform only takes SRT

Plenty of upload forms take SRT and nothing else, which leaves you without positioning at all. Two things still work.

You can shorten the lines, so a caption that would have run under a button does not reach it. The line breaker re-breaks to a character limit without touching timing, and a tighter limit on vertical video is the most common fix for captions colliding with the interface.

Or you can burn the captions into the video, which puts placement entirely under your control because the captions become part of the picture. The cost is that nobody can turn them off, translate them, or read them with a screen reader, which is the trade covered in hardcoded versus soft subtitles. Doing both is reasonable: burn them in for the feed, and keep the file for everywhere else.

One thing this guide will not give you

You will find pages listing exact safe-area margins in pixels for each app. There are none here, because those numbers change when the apps change their layout, and a stale margin is worse than no margin: it reads as authoritative and puts your captions in the wrong place.

Check it in the app instead. Post an unlisted or private test clip, open it on a phone rather than on a desktop preview, and look at where the interface actually falls. It takes a couple of minutes and it stays correct, which a number copied from a blog post does not.

The short version

If captions are getting covered and you are working in SRT, the file cannot help you, so shorten the lines or burn them in. If you are working in WebVTT, position the cues that clash and keep that file as the master, because converting to SRT is a one-way door for the positioning. And confirm the result on a phone, in the app, rather than against a margin someone else published.

If you are starting from the video rather than from an existing file, the caption generator produces a timed track you can review and export as either format, so you can decide which one is the master before the positioning work begins.