What Is twimg? Twitter (X) Media CDN URLs Explained

twimg.com is a plain CDN domain; the subdomains partition the traffic by file type. The official X API data dictionary (docs.x.com/x-api/fundamentals/data-dictionary) shows two of them in its media object examples: pbs.twimg.com for a photo URL (/media/<id>.jpg) and video.twimg.com for an MP4 (/ext_tw_video/<id>/pu/vid/<resolution>/<file>.mp4). Our 2026 sample adds the hosts the documentation does not mention and shows which path families actually appear.

Where the name comes from. The pbs prefix is commonly expanded as "Photo Blobstore" in developer forums; X has not documented the expansion, so treat it as folklore that happens to describe the job. abs is the asset host and shows up in page source for every x.com page load, which is why security-minded users sometimes ask whether twimg is malware: it is not, it is the site's own CDN, and a request to it is a normal part of loading x.com or an embedded tweet.

The one host rule that matters for code. media_url_https on a tweet is always a pbs.twimg.com image, even for a video or a GIF, where it is the poster frame. The playable files live under video_info.variants[] on the video or GIF host. Code that treats media_url_https as "the media" downloads a JPEG for every video.

A photo URL has three parts: the host, the path /media/<media_id> (a 15-character ID such as HUwcJO6WgAAfBCd, not the numeric id_str), and a query string with two keys. format= names the encoding (jpg, png, webp) and name= names the rendition. The legacy form puts the extension in the path and no query string at all: https://pbs.twimg.com/media/<media_id>.jpg. That legacy form is what media_url_https contains in every API payload we have seen, which is where the "my image is smaller than the original" problem starts.

We took 30 random photos from the sample and sent a HEAD request for each at seven renditions plus the default URL and the bare path, 270 requests in all. Every named rendition answered 200 image/jpeg. The sizes below are medians across the 30 photos; the percentage is the rendition's total bytes as a share of the orig total.

Three details fall out of the table. First, name=large is not the original: it matched orig on only 11 of the 30 photos, and across the set it carried a third of the bytes. The 11 matches were photos whose long edge already fit inside the large box, so there was nothing to shrink. Second, name=4096x4096 matched orig on 27 of 30; the three that differed were originals wider than 4,096 pixels (two at 6,064 x 4,043 from NASA and one at 4,275 x 1,408 from NASA Webb). In the full 485-photo sample, 23 photos had a long edge above 4,096 px and the largest was 8,192 px, so the widely repeated claim that X caps uploads at 4,096 px did not hold for these accounts in 2026. Third, ?format=jpg with no name= answered 200 with the medium rendition (61,738 bytes on the probed photo, exactly its name=medium size), while ?name=small with no format= answered 404: format= is required, name= is optional.

Rewrite the API URL. Take media_url_https, split off the extension, and append ?format=<ext>&name=orig: https://pbs.twimg.com/media/HUwcJO6WgAAfBCd.jpg becomes https://pbs.twimg.com/media/HUwcJO6WgAAfBCd?format=jpg&name=orig. Keep the extension the API gave you as the format= value. In our probes a PNG source (/media/<id>.png) requested as ?format=jpg&name=orig answered 404, while ?format=png&name=orig answered 200 with the same 520,267 bytes as the plain .png URL. The reverse direction worked on the JPEG we tried (?format=png&name=small returned image/png, ?format=webp&name=small returned image/webp at 16,580 bytes), but it is a transcode of a stored JPEG, not a lossless original, so there is no reason to ask for it unless you want WebP for a thumbnail grid.

The legacy colon syntax still works. https://pbs.twimg.com/media/<id>.jpg:orig answered 200 with the same Content-Length as ?format=jpg&name=orig (321,547 bytes on the probed photo). Older scripts and browser extensions still rely on it. It is undocumented and the query-string form is what x.com itself requests, so write new code against ?format=&name=.

Do not assume large is enough. For a thumbnail or a preview, name=small (4.8% of the bytes) or name=medium (13.1%) is the right call and saves real bandwidth. For an archive, a dataset or anything you will resize yourself, request name=orig; the median original in our 30-photo sample was 995,619 bytes and the largest was 3,895,817 bytes, so budget storage accordingly. The 485 photos in the full sample had a median long edge of 2,048 px, 225 exceeded 2,048 px, and the most common dimensions were 1,920 x 1,080 (41 photos), 4,096 x 2,304 (22) and 3,000 x 2,000 (21).

Video posters follow the same rule. The thumbnail URL on a video, https://pbs.twimg.com/amplify_video_thumb/<media_id>/img/<file>.jpg, accepts ?format=jpg&name=orig too: the probed poster grew from 104,759 bytes at the default URL to 178,602 bytes at orig.

A video in a tweet payload is one media object of type: "video" whose video_info carries aspect_ratio, duration_millis and a variants[] array. Every one of the 191 videos in our sample had exactly one application/x-mpegURL variant (the HLS playlist, no bitrate key) plus between two and five video/mp4 variants, each with a bitrate. The path encodes the resolution, so you can read the ladder without parsing anything else: https://video-s.twimg.com/amplify_video/<media_id>/vid/avc1/1280x720/<file>.mp4?tag=29.

Pick the highest bitrate, not the last element. The variants array is not sorted by quality in a guaranteed order; filter to content_type == "video/mp4" and take the maximum bitrate. The X Developers walkthrough of the v2 variants field (dev.to/xdevs/get-a-video-url-from-twitter-api-v2-1713) shows the same ladder shape on the official API: 256,000 / 832,000 / 2,176,000 / 10,368,000 plus an .m3u8 with no bit rate. The 25,128,000 rung is the 4K (3840x2160) rendition that SpaceX, NASA and NatGeo upload; it did not exist in older ladders and your downloader should not assume 1080p is the ceiling.

The HLS playlist is for players, the MP4 is for files. The .m3u8 on video-s.twimg.com (1,628 bytes on the probed video) references fragmented MP4 segments and an audio track; a browser <video> element cannot play it without an HLS library on most desktop browsers, and a downloader has to stitch segments. The progressive MP4 renditions are single files: the probed 1080x1920 rendition was 8,401,119 bytes, answered 200 video/mp4 with Cache-Control: public, max-age=604800, and the identical path on video.twimg.com returned the same byte count. The ext_tw_video/<id>/pu/vid/ family that the X data dictionary and the X Developers walkthrough show did not appear once in this sample: all 933 video renditions from these six accounts used amplify_video, so a downloader should match on the host and the .mp4 extension rather than on a path prefix.

Animated GIFs are MP4s. A type: "animated_gif" object has a /tweet_video_thumb/ poster on pbs and a single video/mp4 variant under /tweet_video/ on the video host, with a bitrate of 0. There is no GIF file to download; convert the MP4 if you need one.

Avatars live under https://pbs.twimg.com/profile_images/<numeric_id>/<file>_<size>.jpg. The user object from /twitter/user/info and the author block on every tweet carry the _normal form, and the size is a plain suffix swap on the file name. We probed three forms on one public organization account: the _normal file was 1,807 bytes, _400x400 was 8,476 bytes and the suffix-free file was 12,302 bytes, all 200 image/jpeg with Cache-Control: public, max-age=604800. The suffix-free form was the largest of the three, which is what you want for a profile card.

Why profile image links rot. The <numeric_id> segment is the ID of the upload, not of the user. When an account changes its avatar, a new upload ID is minted and the old path stops resolving. We probed a made-up file under a real upload ID and got 404 with Cache-Control: max-age=300, must-revalidate, which is also what a stale avatar path returns. Store the user ID, not the avatar URL, and re-read /twitter/user/info (18 credits, $0.18 per 1,000 profiles) when a picture breaks. Caching a _400x400 URL for a week in your own app is fine; caching it for a year is how dashboards end up full of broken circles.

Media IDs are not tweet IDs. The /media/<id> segment (HUwcJO6WgAAfBCd) is a base64-style key that also appears as the tail of media_key (3_2111093270277160960, where the prefix 3_ means photo, 13_ means video and 16_ means animated GIF, and the number is id_str). The tweet's own id is a different snowflake. You cannot derive a pbs URL from a tweet ID; you have to read the tweet.

The most-searched variant of this keyword is a bug report: images from pbs.twimg.com are broken in a React app, a Discord embed, a Notion page or a spreadsheet. The usual guesses are a referrer check or CORS. We tested both and neither was the cause on this CDN in 2026. The failures we could reproduce were all malformed URLs.

CORS and referrers, measured. All 30 name=orig probes without any browser headers returned Access-Control-Allow-Origin: *; when we sent an Origin header the CDN echoed it back, which is what a credentialed cross-origin fetch needs. A third-party Referer changed nothing. The browser default referrer policy, strict-origin-when-cross-origin (MDN, developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy), sends only your origin to pbs on a cross-origin image load, and the CDN served the file anyway. If your hotlink fails, print the exact URL the browser requested from the network tab and compare it to the table above before touching headers.

The React-specific trap. The & row explains most "images in pbs.twimg.com/media are broken on react" reports: a developer copies src="...?format=jpg&name=small" out of rendered HTML into a JSX string literal. In HTML the browser decodes & to &; in a JavaScript string it stays literal, the CDN sees a parameter named amp;name, and answers 404. The fix is to build the URL from media_url_https in code (see the helper above) rather than pasting markup.

Caching behavior you can rely on. Successful responses carried Cache-Control: max-age=604800 for images (22 of 30 orig probes as max-age=604800, must-revalidate, 8 as public, max-age=604800 from a server: cloudflare edge) and the same seven-day lifetime on MP4s; 404s carried max-age=300 or max-age=14400. Per RFC 9111 (rfc-editor.org/rfc/rfc9111), max-age makes the response stale after that many seconds and must-revalidate forbids a cache from reusing a stale copy without checking the origin, so a proxy in front of your app will re-validate a week-old image rather than serve it forever. Deleted media returns 404 on the next re-validation, which is the right behavior for a tweet that was taken down.

You never have to guess a twimg URL. Every tweet endpoint on TwitterAPI.io (/twitter/user/last_tweets, /twitter/tweet/advanced_search, /twitter/tweets, /twitter/user/mentions, and the rest) returns the tweet's extendedEntities.media[] array as X's own clients see it, and no X account or developer app is needed for reads. The fields you use are the same ones X's data dictionary describes for its media object, under X's legacy names.

What a read costs. Tweet endpoints bill 15 credits per tweet returned, $0.15 per 1,000 tweets, with a 15-credit minimum per request; a full 20-tweet page of last_tweets is $0.003. The study behind this page read 980 tweets in 51 requests for 14,700 credits, $0.147. The official X API's pay-per-usage rate card (docs.x.com/x-api/getting-started/pricing) charges $0.005 per post read, so the same 980 posts would have cost $4.90, and per 1,000 tweets it is $5 against $0.15, about 33x; the X card also caps pay-per-usage at 3 million post reads a month and offers $20 of credits on a first saved card plus a match of the first auto-recharge up to $50. New TwitterAPI.io accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days); purchased credits never expire. Rate limits start at 0.2 requests per second before the first payment and 20 once paid; full tiers are on the pricing page.

Downloading is a separate HTTP call to the CDN, not to us. The script below reads a timeline, rewrites each photo to name=orig, picks the top-bitrate MP4 for each video, and fetches the files directly from pbs and video-s. Those CDN fetches are not API calls and are not billed; what you pay for is the tweet read. Respect the content: these are the authors' files, X's terms govern reuse, and organization accounts are the sensible target for bulk archives.

To get real twimg URLs to probe we pulled the latest posts of six media-heavy organization accounts: NASA, National Geographic, SpaceX, NASA Webb, ESA and Nintendo of America. Two accounts returned fewer than ten pages (SpaceX 120 posts, Nintendo of America 60), which is why the total is 980 rather than 1,200.

Across the 559 posts that carried media, 492 had a single item, 27 had two, 14 had three and 26 had the maximum of four; SpaceX accounted for 21 of the four-image posts. Of the 485 photos, 479 were JPEG and 6 were PNG, which is the practical reason the format= value must come from the API rather than being hard-coded. The reposts in the sample (NASA 90 of 200, ESA 83 of 200) carry the original author's media under retweeted_tweet, with the same URL shapes.

What the sample cannot show. These are large institutional accounts with professional media; a consumer timeline will have more phone-sized JPEGs and fewer 4K uploads, so the bitrate ladder and the share of originals above 4,096 px will differ. The HEAD probes were sent from one region on one day; CDN headers (the server: cloudflare split in particular) can vary by edge. The probes measured Content-Length, not visual quality.

Question. What do the media URLs attached to tweets from media-heavy organization accounts look like on X's twimg CDN: which hosts, which path families, how many renditions, and what does each name= rendition weigh?

Accounts and endpoint. NASA, NatGeo, SpaceX, NASAWebb, esa and NintendoAmerica, read through /twitter/user/last_tweets with userName=<account>, default includeReplies (false), newest first, up to 10 pages of 20 per account. 51 requests, 980 posts, 14,700 credits, $0.147.

Window. The most recent posts of each account at collection time in 2026; the per-account window runs from the oldest to the newest post returned and differs by account.

Sample. 980 posts, 559 with media, 692 media items (485 photos, 191 videos, 16 animated GIFs). For the rendition probe we drew 30 random /media/ photos (seeded, so the draw is reproducible) and sent unproxied curl -sI HEAD requests at nine URL forms each, plus 22 extra probes covering the video host, the :orig legacy form, format= transcodes, profile images, the asset host, and the hotlink failure cases. Every number on this page is in results.json next to the analysis script and the gzip-compressed raw pages.

What it cannot show. Six accounts are not X; consumer accounts upload different sizes and fewer 4K videos. HEAD responses report bytes and headers, not visual quality or decode time. Headers were read from one network vantage on one day, and CDN behavior can change without notice; re-run the probes before relying on a specific header value.

Privacy. Aggregates only. All six accounts are public organizations, so the raw timelines are committed in compressed form and the probed media URLs are listed in sample.json. No individual's posts, media or profile images were analyzed, and the one profile-image URL probed belongs to a public organization account.