Instagram sends 4000 px photos to your phone

Toggle (toggle.social) is an iPhone app that opens Instagram, YouTube, TikTok, X, Threads, Reddit, LinkedIn, Facebook and Snapchat inside one app, with the parts built to keep you scrolling switched off. Each service opens as its own mobile website inside Toggle. Building that meant watching what Instagram's page downloads, and one thing stood out enough to write up: the size of the photos. This page is the measurement, its method and its limits. Nothing here is about the Instagram app, which wasn't measured.

The question

Does Instagram's mobile web feed download photos at the size a phone screen can show, or larger? And if larger, how much of the data in the first half minute of a session is that excess?

What Instagram's own pages say about photo size

Instagram's help page on image resolution says a shared photo is uploaded "at the best quality resolution possible (up to a width of 1080 pixels)", that a photo between 320 and 1080 px wide is kept at its resolution, and that "if you share a photo at a higher resolution, we size it down to a width of 1080 pixels". The Instagram Graph API's IG Media reference, which gives developers a media_url per post, lists no dimensions or size candidates at all, and the content publishing guide specifies only the format (JPEG). So the public documents describe a 1080 px ceiling and say nothing about what the feed serves.

Method

The measurement is Toggle's, taken while reducing what its Instagram pane downloads, in October 2026.

• What was read. Instagram's mobile website (the page a phone browser gets at instagram.com), signed in to one account, opened inside Toggle's WebKit view. The feed arrives as JSON responses from Instagram's feed API, plus inline JSON blocks in the first document. Each photo in those responses carries a list of image candidates: several widths, and the original.
• Screen. A 1206 px wide screen, the iPhone 17 Pro class: 402 points at a device pixel ratio of 3 (MDN defines devicePixelRatio as the ratio of physical pixels to CSS pixels).
• Network tooling. Toggle's debug builds route the web views through tools/netem, a throttling CONNECT proxy that gives each connection its own turn, so the link can be set to LTE, Wi-Fi or 3G class rates without touching the system, and its per-host stats count bytes while downloads are still in flight (the page's own Resource Timing lists a download only once it finishes). tools/bench NAME bytes counts megabytes per launch and per app open.
• What was changed. Toggle's capImages reads each feed response as it streams in and removes image candidates wider than 1.35 times the screen's pixel width before the page sees them. The CDN URLs are signed, so a smaller size can't be written into a URL; the only lever is the list of candidates the response already offers.
• What was compared. Bytes downloaded in the first 30 seconds after opening Instagram, with Instagram's own choices and with the pruned candidate lists, under the same conditions.

Results

Two other behaviours belong with the numbers. The CDN URLs are signed, which rules out the usual trick of rewriting a size parameter. And on a connection Toggle reads as slow, the cap tightens to the screen's width and video renditions above 720 by 1280 are dropped from the manifests as well; the 32 MB to 18 MB figure is the image cap alone.

What it means for people on metered or slow connections

A 1206 px wide screen cannot show a 4000 px photo at full resolution; the extra pixels are downscaled on the phone. In this measurement that excess was close to half the data of the first half minute. On a metered plan that is data paid for and never seen. On a slow link it is time: a feed photo of 1 to 2 MB takes several times longer to arrive than one sized for the screen, and photos lower in the feed queue behind it.

The fix doesn't lower quality on the screen. Toggle keeps every candidate up to 1.35 times the screen's width, which leaves headroom for Instagram's own crops and zoom, and drops only what the display can't resolve. This is what the "on a slow connection Toggle loads smaller images and fewer videos ahead" line in how Toggle works refers to.

The experiment with devicePixelRatio is worth knowing about for anyone trying the same from a browser extension: pretending to be a 2x screen changed the menu Instagram's server offered (an 804 px candidate appeared) but not the page's preference for the original, so it saved nothing and was reverted.

Limits of the measurement

• One account, one feed. The mix of photos, carousels and video in a feed drives the byte count. Another account's first 30 seconds would give other totals; the 3000 to 4000 px originals are what this feed's posts carried.
• One month. October 2026. Instagram changes its page and its API without notice; the candidate lists, the page's choice among them and the signed URLs could all differ later.
• The mobile website, not the app. The native Instagram app has its own image pipeline and was not measured. Nothing here says the app does the same.
• Bytes, not dollars. 32 MB and 18 MB are what the proxy counted. Translating them to a bill depends on the plan.
• A single before-and-after pair. The two 30-second figures were taken under the same conditions, not averaged over many runs. Treat the gap as the finding and the exact numbers as one sample.
• Not independent. The measurement was made while building Toggle, by its maker. The method is here so anyone can check it.

Terms used on this page

• Image candidate. One entry in the list of sizes a feed response offers for a photo: a URL plus a width and height. The page picks one to show.
• Original. The largest candidate in the list, 3000 to 4000 px wide in this feed, 1 to 2 MB each.
• Screen width in pixels. Points times devicePixelRatio: 402 by 3 on the screen measured, so 1206 px. Images wider than that are downscaled by the phone before display.
• Signed URL. A CDN address carrying a signature over its parameters; changing the size in it invalidates the signature, so the CDN refuses it.
• Pruning. Toggle's capImages removing candidates wider than 1.35 times the screen's pixel width from a response before the page reads it. The page then chooses from what is left.
• First 30 seconds. The byte-count window used for the 32 MB and 18 MB figures, measured from opening Instagram in Toggle.

How to reproduce it

In general terms: open Instagram's mobile website in a browser or web view whose network traffic you can see, signed in. Capture the feed API responses and look at each photo's image candidates; note the widths and the largest one's file size. Then watch which candidate the page requests for a photo on screen, and compare its width to your screen's width in physical pixels (screen.width times devicePixelRatio). To measure the excess, count bytes for a fixed window after the page opens, once with the responses untouched and once with candidates above a chosen multiple of the screen's width removed from the responses before the page reads them. Because the responses stream and the page reads them before they finish, the rewrite has to work on complete lines as they arrive, and the inline JSON in the first document has to be rewritten too. Keep the link rate, account and window the same for both runs, and expect your totals to differ from these.

If you want the shorter version: Toggle does this for Instagram already, on iPhone, as part of opening it without the feeds built to keep you scrolling; the Instagram page lists what else it changes, and is Toggle safe covers what the rewrite can and can't see.