YouTube timedtext Returns 200 With an Empty Body: Why It Happens

Requests to https://www.youtube.com/api/timedtext can return HTTP 200 with a zero-byte body. The endpoint is answering, and the request is missing something: a proof-of-origin token that YouTube mints inside the player. That token does not appear in the page HTML, and it cannot be derived from ytInitialPlayerResponse. Measured in real Chrome on 18 September 2026.

The endpoint answers 200 because the request is well formed, the video is public, and the caption track exists. The empty body is a separate decision, made when YouTube checks the request for a proof-of-origin token. That token is minted inside the player while the video plays, and it rides on the player's own caption request. A script that reads captionTracks[].baseUrl from the player response and fetches it sends a request with no token and receives an empty 200 rather than an error.

The token is not in the page HTML, not in ytInitialPlayerResponse, and not derivable from either, because the player computes it from state that does not reach the document. The MAIN-world bridge in prepublish-extension/src/content/youtube-main.js exists for that reason.

captionTracks[].baseUrl is a real URL for a real caption track, and fetching it returns nothing while reporting success at the HTTP layer. A scraper with no guard writes an empty string to the database and moves on.

Every row below was measured in real Chrome and Chrome for Testing on 18 September 2026.

The first two rows are the confusing ones. The same URL, fetched with the page's own cookies, from the page's own origin, in a browser that already loaded the video, returned nothing. Cookies do not carry the token, and origin does not carry it either.

Rows seven and eight close off the routes that forum answers recommend. The InnerTube get_transcript call, sent with the parameters the transcript panel uses, answered HTTP 400 with FAILED_PRECONDITION and the message Precondition check failed. The rendered panel opens in a signed-out headless browser and never resolves its continuation, so it produces zero segments.

The URL the player requested, the one that returned 46,010 bytes, carries these parameters.

Read that list as three groups. pot is the part that was missing. fmt is the part you choose, because the body you want is JSON3 rather than the default timed-text document. tlang is the part you delete: a URL carrying it returns a body in the viewer's language while lang still names the original track, so a pull that stores the body labels a translation as the original.

We did not attempt to construct a pot. The measurements describe what the player sent, and the approaches below reuse the player's own request.

Approach 1: observe the player's own request from a MAIN-world content script

A content script running in the page's MAIN world at document_start replaces window.fetch and XMLHttpRequest.prototype.open with wrappers that record any URL whose pathname is exactly /api/timedtext on a YouTube host. The wrapper therefore keeps a URL that already carries the token, and the caller refetches it with &fmt=json3 forced, which is how the 46,010-byte body was obtained. The implementation ships in prepublish-extension/src/content/youtube-main.js and prepublish-extension/src/content/youtube.js.

Cost and breakage:

• It needs a real browser with the video open. There is no headless path, and row five is why.
• The token only exists after the player requests a caption body, which requires a track to be switched on, so the script drives setOption('captions', 'track', ...) instead of clicking the CC button, which is not always present.
• A pre-roll ad owns the player. Until the ad finishes, getOption('captions', 'tracklist') returns an empty list and the video's own caption tracks do not exist yet.
• The captured URL arrives from the page, which the page can also write to. Validate the protocol, the host, and the exact path before storing or fetching it.

Those timings were measured against live YouTube on 18 and 19 September 2026.

Approach 2: yt-dlp with curl_cffi

yt-dlp does not replay a browser request. It succeeds for a different reason: the caption body request goes out through curl_cffi, which presents a browser TLS fingerprint, and the timedtext endpoint answers HTTP 429 to requests without one. A build that lacks curl_cffi therefore fails captions while metadata keeps working. The server-side implementation is in prepublish-be/internal/infrastructure/youtube/channel_dlp.go.

Measured on the production host on 19 September 2026:

Without curl_cffi, yt-dlp cannot impersonate a browser TLS fingerprint, falls back to the mweb client for subtitles, and that client needs a PO token, so the caption download returns nothing. A residential proxy alone does not fix it. Neither does a newer yt-dlp.

The costs are a Python environment that can carry the curl_cffi wheel, an egress proxy if you run from a datacentre address, and upkeep that includes release cadence. The current stable release was 2026.8.19, 30 days old on 18 September 2026, while the newest nightly on PyPI was 2026.9.16.232951.dev0 at 1.8 days old, with a median gap of 1.5 days between the 15 most recent PyPI releases.

Server-side timings, measured 18 and 19 September 2026: a cold pull takes 37.1 s and a cached read takes 4 ms. Three consecutive cached reads measured 3.9 ms, 4.4 ms, and 3.5 ms, and ten concurrent cold requests for one video produced exactly one yt-dlp run, one stored row, and ten identical bodies. Source: prepublish-be/internal/domain/service/video_transcript_service.go.

Where this breaks: the plain zip-app build from GitHub releases cannot bundle curl_cffi, so it cannot fetch captions at all, and the failure arrives as a 429 that reads like a network block.

Approach 3: the official Data API and its ownership requirement

YouTube's own captions.download method requires the user to have permission to edit the video, accepts the youtube.force-ssl or youtubepartner scope, and costs 200 quota units per call. A request without sufficient permission returns 403 forbidden (Google's captions.download reference). For a video you own or manage, this is the documented and stable route.

For another creator's public video it is not an option. The permission the method requires is edit access to the video, and there is no scope an ordinary developer can request that substitutes for it.

The token-bearing URL returned HTTP 200 with a zero-length body under a HeadlessChrome user agent, and the full JSON3 body after the same session switched to a normal Chrome user agent. That pair was measured on 18 September 2026 and the two requests differed in nothing else.

Two caveats belong here. This is an observation of behaviour, not documented policy: YouTube does not publish the rule that produces it, so nothing here can say whether the user agent is used alone or as one signal among several. It is also not a substitute for the token. Rows one and two were sent a token-less URL from real Chrome with a normal user agent and returned zero bytes, so a request does not start working when it claims to be a browser. It starts working when it carries the token, and the user agent gate sits on top of that.

Nothing here is contractual. The timedtext endpoint has no public documentation, the token handshake is an implementation detail, and YouTube can change any part of it without notice. Detection happens when a pull breaks, so anything built on this needs a canary that exercises the production path.

A working design probes one public video twice: metadata with a non-empty title, and captions with a text floor. prepublish-be/scripts/ytdlp-canary.sh uses that shape. It asks for the en track the way production does, so a machine translation cannot satisfy the check. The caption prose must reach 200 characters, and the probe reports ok, blocked, or broken with exit codes 0, 2, and 1. The distinction matters because the fixes are opposite. blocked means YouTube refused the egress IP, and a proxy or cookies file is the fix. broken means the binary or the extractor is wrong, and a proxy will change nothing. The same script checks for the missing-impersonation warning before either, because a 429 from a build without curl_cffi arrives in the same shape as a network block and is not one.

That canary is exposed as GET /health/ytdlp, which answers 200 while the probe passes and 503 for blocked, broken, or unknown, with an in-process run every 30 minutes (prepublish-be/internal/application/handler/health_handler.go). The binary refreshes nightly with a canary and rollback (prepublish-be/scripts/ytdlp-update.sh, scheduled by ops/systemd/prepublish-ytdlp-update.timer at 03:30 UTC), and the container image pin is bumped weekly.

Two limits sit below the canary. A canary video can pass while a specific video fails, because that track may be absent, restricted, or in a language the request did not name. The browser path adds a second: while a pre-roll ad is playing, the caption tracks do not exist yet.

If the goal is a transcript rather than a working scraper, the transcript endpoint runs the yt-dlp path server-side and keeps the result for 30 days. That turns the 37.1 s cold pull into a stored row that reads in single-digit milliseconds (prepublish-be/internal/domain/service/video_transcript_service.go). The same pull is reachable from the free tools and over MCP at the MCP server, for callers that would rather not run yt-dlp themselves.

Everything above concerns caption tracks that a creator published on a public video and that the player serves to any signed-out viewer. None of the measurements came from private, members-only, or otherwise restricted content.

If a track is not served to a signed-out browser, there is no player request to observe and nothing to replay. Reaching one would mean working around an access control, which is a different problem from the one this article describes.

The endpoint never stopped serving captions to the player. It stopped serving them to callers without the player's token, so the failure is in who the request comes from, not in whether the video has captions.