Every price comparison for social-media data argues about cost per request. Almost none of them mention the thing that actually varies by two orders of magnitude between platforms: how many bytes come back.
I measured it. One public profile, one request, eight platforms, response body as received. The spread between the smallest and the largest is 287 times.
The measurements
| Platform | Response size | Relative to GitHub |
|---|---|---|
| Threads | 153 KB | 287× |
| 140 KB | 262× | |
| 132 KB | 247× | |
| TikTok | 89 KB | 167× |
| Linktree | 53 KB | 99× |
| Mastodon | 931 B | 1.7× |
| Bluesky | 633 B | 1.2× |
| GitHub | 534 B | 1× |
Measured 10 September 2026. One profile per platform, response body as transferred, compressed, no media assets followed. Method and caveats at the bottom — read them before you quote these numbers.
Why the gap is that big
It isn't randomness and it isn't sloppiness on the big platforms. It's two different delivery models that happen to answer the same question.
GitHub, Bluesky and Mastodon have a public API. You ask for a profile, you get a profile: a JSON object with the fields a profile has. 534 bytes is roughly what a name, a bio, a follower count and a handful of URLs weigh when nothing else is attached to them.
Threads, Instagram, Pinterest, TikTok and Linktree have a web page. There is no public profile endpoint, so a profile request is a page request, and a modern social page carries its entire initial render state inline — the profile you asked for, plus the first screen of posts, plus recommendation payloads, plus feature flags, plus i18n strings, plus tracking configuration. The profile is in there. It is maybe 2% of what arrives.
That's the whole explanation. Platforms with an API send you a profile. Platforms without one send you an application.
What the extra bytes cost you
Bandwidth reads like a rounding error until you look at where it gets billed.
Data transfer is metered separately on most scraping platforms. Apify, for one, bills proxies, storage and data transfer out of the same credit balance as the actor run itself — I worked through that arithmetic here. The per-result price you compared is the actor. The bytes are extra, and they are 287× more extra on Threads than on GitHub.
Residential proxy bandwidth is the expensive kind. Residential proxies are commonly priced per gigabyte, not per request. At that pricing, 10,000 Threads profiles is about 1.5 GB and 10,000 GitHub profiles is about 5 MB. Same job description, same row count in your database, three orders of magnitude apart on the proxy invoice.
Parse time and timeouts scale with the payload. A 153 KB HTML document that has to be parsed and traversed to find one bio string is not the same operation as reading a field off a 534-byte JSON object. This is where the timeouts come from when you fan out a batch.
Your own egress counts too, if the data crosses a cloud boundary on the way to storage.
None of this appears in a "$2.60 per 1,000 profiles" comparison. It appears on the invoice.
What to do with this
Three things, whether or not you use my API.
Budget bandwidth per platform, not per request. A mixed workload of Instagram and Bluesky is not one number. If you're sizing a scraping budget on an average, the average is meaningless — the distribution here has no middle. Five platforms are in the 50–150 KB band, three are under 1 KB, and nothing sits between 1 KB and 50 KB.
Expect page-scraped platforms to be less stable. A response that is 98% render state is a response whose shape changes whenever the front end ships. API-backed platforms version their contracts; page-backed ones don't have one to version.
Ask whoever you buy from whether bandwidth is included. It's a yes-or-no question and the answer changes your unit economics by more than the sticker price does.
What this costs on HonestHook
I build HonestHook, so discount this section accordingly.
An Instagram profile call costs 1 credit. A GitHub profile call costs 1 credit. The 287× byte difference is real and it is mine to absorb — the price you pay does not move with the payload, because the payload never reaches you. You get the same normalized profile shape from every platform, which for Threads means roughly 2% of what arrived at my end and for GitHub means very nearly all of it.
That is the actual product, stated plainly: I eat the bandwidth variance and hand you a fixed number. Every key gets 1,000 credits a month free with no card; prices are at /pricing, generated from the same catalogue that serves the requests.
Method, and what would make these numbers wrong
I am publishing this because nobody else seems to have measured it, not because the measurement is bulletproof. Where it's thin:
- One profile per platform, one day. Eight samples. A profile with 10,000 posts and a profile with three will not weigh the same on a page-scraped platform, and I did not sweep that range.
- These are on-the-wire bytes, compressed. The figures are what the transfer actually costs, not decoded document size, and the two are very different: Medium's profile page decodes to roughly 270 KB but crosses the wire at about 35 KB; SoundCloud's decodes to about 110 KB and crosses at about 16 KB. If you compare these against a number someone measured after decompression, you are comparing two different quantities.
- Media not followed. Avatars and post images aren't counted. Fetch those and the page-scraped platforms get worse, not better.
- Point-in-time. Any of the five page-scraped platforms could ship a change next week that moves their number 30%. The three API-backed ones essentially can't.
If you re-run this and get something different, I'd like to know. The claim I'm confident in isn't "Threads is exactly 153 KB" — it's that the gap between API-backed and page-backed platforms is two to three orders of magnitude, and that no pricing page on either side of the market mentions it.
Measurements taken 10 September 2026 against live public profiles, one per platform. HonestHook figures are generated from the live catalogue and are current as of page load.