Why captions break on an iPhone, and what actually fixes it
YouTube draws its captions itself, as part of its own player, inside its own frame. On a desktop that simply works. On an iPhone it works too — right up until the moment iOS decides to take the video out of the page and play it in the system's own fullscreen player. At that point the operating system is drawing the video, not the web page, and the caption layer that belonged to the page is simply gone. That is the entire bug, and it is why captions on the same video behave differently on a phone than on a laptop.
Two things stop that handover. The first is asking for inline playback explicitly, so iOS keeps the video in the frame instead of promoting it to the system player. The second is not offering the player's own fullscreen button as the way to go fullscreen, because pressing it on an iPhone is precisely the handover that loses the captions. Fullscreen here is applied to the player's whole shell — picture, controls and all — which the page keeps drawing itself.
With both in place, YouTube's real caption tracks keep rendering on an iPhone, and the caption menu in the control bar lists whatever languages the video actually offers. The menu stays empty until playback begins, which is not an oversight: the player exposes no track list at all until media has started loading, so there is genuinely nothing to show before then.
The subtitle-file loader is the separate, guaranteed path. It parses a file you supply and draws the lines in this page's own elements, so it does not depend on any platform behaviour — and it is the only option for a video that has no captions of its own. It cannot be filled from YouTube's tracks: caption text is not exposed by the player's interface, and the endpoint that serves it is not reachable from a browser.
What rotation does to the size of the picture
Turning a video 90° inside a screen of the same shape always costs you size, and it is worth knowing why before assuming something is broken. A widescreen video is roughly 16 units across for every 9 tall. Stand it on its end and it becomes 9 across for every 16 tall, while the screen it has to fit inside is still the wide way round. The height of the screen now limits the long side of the picture, so the video ends up occupying a tall strip through the middle with empty space either side.
That is geometry rather than a limitation of the player: no arrangement makes a rotated widescreen picture fill a widescreen screen. The player already sizes the turned frame as large as it can possibly go, which is why fullscreen is worth using once rotated — a bigger screen means a bigger strip.
Fullscreen here is applied to the whole player rather than to the video frame, which matters more than it sounds. Handing the screen directly to the platform's frame would take the rotation and the subtitle layer with it, since both belong to this page and not to theirs. On iPhone, where a page cannot request true fullscreen for anything other than a video element, the player falls back to filling the screen with ordinary layout instead — visually the same, and it keeps everything this page draws.
Getting subtitle timing to line up
A subtitle file is timed against one specific copy of a video. Re-uploads, regional cuts and versions with different intros all shift the timing, so a file that is perfect for one copy can run consistently early or late on another. This is the usual reason subtitles that "don't work" are in fact working and simply displaced.
The fix is a single offset applied to every line at once. Find a moment where someone clearly says something, note whether the text arrives before or after, and nudge in half-second steps until the two meet. Drift that grows over the length of a video is a different problem — that means the two copies run at different frame rates, and no fixed offset will hold across the whole thing.
Both common formats are accepted. SubRip files, ending .srt, number each line and separate the timestamps with commas; WebVTT files, ending .vtt, start with a WEBVTT header and use dots. The difference is cosmetic and the parser here takes either without being told which is which. If you need to convert or clean up subtitle text first, the subtitle editor handles that, and OCR can pull text out of hard-burned captions.