ft's media parser at src/graphql-bookmarks.ts:274 uses m.media_url_https as-is — a pbs.twimg.com/media/<hash>.jpg URL with no ?name= query parameter. X serves the medium variant (~1200px on the long side) for parameter-less URLs. There's no way for ft (or downstream tools) to opt into the larger variants X exposes (large ~2048px, 4096x4096, orig uncapped) without modifying source.
For high-DPI / retina displays the ~1200px default looks soft when stretched to lightbox sizes. The fix is small: append ?name=<quality> to the URL before fetching, controlled by a flag.
Empirical verification (May 2026)
Tested against an 8192×5427 original (Twitter Blue / high-res upload — the case where all variants meaningfully differ):
| URL variant |
Bytes |
Dimensions |
?name=thumb |
5 kB |
150×150 |
?name=small |
22 kB |
680×450 (typical) |
?name=medium (= no-param default) |
151 kB |
1200×795 |
?name=large |
365 kB |
2048×1357 |
?name=4096x4096 |
1,201 kB |
4096×2714 |
?name=orig |
2,764 kB |
8192×5427 |
All four high-end variants return distinct files for this image. Default URL (no parameter) = medium.
Real-world distribution
Sampled across a ~6,300-photo corpus (May 2026), grouped by original-upload width:
| Original width |
Photos |
% |
| ≤1200 (all variants return the same file) |
2,935 |
46.8% |
1201-2048 (large is a real upgrade over medium) |
2,208 |
35.2% |
2049-4096 (4096x4096 is a real upgrade over large) |
1,117 |
17.8% |
>4096 (orig is the only path past 4096) |
11 |
0.2% |
~53% of photos benefit from some variant above medium. Highest-resolution uploads (4K+ Twitter Blue) genuinely need orig to fetch the full file.
Suggested scope
A flag accepting four useful values: medium | large | 4096x4096 | orig.
- medium — current default; backward compatible; smallest disk footprint
- large — ~2048px cap; cheap upgrade for the ~35% bucket where it makes a difference
- 4096x4096 — 4096px cap; meaningful for 4K-era uploads (~18% bucket)
- orig — uncapped; only path to >4096px on the highest-resolution Blue uploads
thumb (150px) and small (~680px) are out of scope as primary assets — clients with their own thumbnail-generation pipeline derive these locally from a higher-quality source.
The flag would naturally apply to:
Out of scope: profile images use a different URL pattern with size embedded in the filename (<filename>_400x400.jpg); videos use video_info.variants[] with per-bitrate URLs (bookmark-media.ts:150-153 already picks the highest-bitrate variant). Neither responds to ?name= so the flag doesn't apply.
Implementation note
Mechanically tiny: append ?name=<quality> to each pbs.twimg.com/media/... URL before passing to the fetch step. Likely 2-3 lines in the URL-construction or fetch entry point, plus the flag plumbing on ft sync / ft fetch-media.
One design surface to consider
Quality changes between runs have implications for existing cached files — eager re-fetch on flag change, lazy upgrade on next sync, leave-old-alone, or explicit --rebuild-media-quality command. Appropriate strategy is a design call.
ft's media parser at
src/graphql-bookmarks.ts:274usesm.media_url_httpsas-is — apbs.twimg.com/media/<hash>.jpgURL with no?name=query parameter. X serves the medium variant (~1200px on the long side) for parameter-less URLs. There's no way for ft (or downstream tools) to opt into the larger variants X exposes (large~2048px,4096x4096,origuncapped) without modifying source.For high-DPI / retina displays the ~1200px default looks soft when stretched to lightbox sizes. The fix is small: append
?name=<quality>to the URL before fetching, controlled by a flag.Empirical verification (May 2026)
Tested against an 8192×5427 original (Twitter Blue / high-res upload — the case where all variants meaningfully differ):
?name=thumb?name=small?name=medium(= no-param default)?name=large?name=4096x4096?name=origAll four high-end variants return distinct files for this image. Default URL (no parameter) =
medium.Real-world distribution
Sampled across a ~6,300-photo corpus (May 2026), grouped by original-upload width:
largeis a real upgrade overmedium)4096x4096is a real upgrade overlarge)origis the only path past 4096)~53% of photos benefit from some variant above
medium. Highest-resolution uploads (4K+ Twitter Blue) genuinely needorigto fetch the full file.Suggested scope
A flag accepting four useful values:
medium | large | 4096x4096 | orig.thumb(150px) andsmall(~680px) are out of scope as primary assets — clients with their own thumbnail-generation pipeline derive these locally from a higher-quality source.The flag would naturally apply to:
legacy.entities.media[].media_url_https— current code site)cover_media.media_info.original_img_url, once Article extraction dropscontent_state,cover_media,media_entities, and 6 other fields ft already has access to #148 lands)media_entities[].media_info.original_img_url, once Article extraction dropscontent_state,cover_media,media_entities, and 6 other fields ft already has access to #148 lands)Out of scope: profile images use a different URL pattern with size embedded in the filename (
<filename>_400x400.jpg); videos usevideo_info.variants[]with per-bitrate URLs (bookmark-media.ts:150-153already picks the highest-bitrate variant). Neither responds to?name=so the flag doesn't apply.Implementation note
Mechanically tiny: append
?name=<quality>to eachpbs.twimg.com/media/...URL before passing to the fetch step. Likely 2-3 lines in the URL-construction or fetch entry point, plus the flag plumbing onft sync/ft fetch-media.One design surface to consider
Quality changes between runs have implications for existing cached files — eager re-fetch on flag change, lazy upgrade on next sync, leave-old-alone, or explicit
--rebuild-media-qualitycommand. Appropriate strategy is a design call.