Searching for how to download millions of Instagram comments usually means one of three jobs: a brand measuring a campaign that ran across dozens of posts, a researcher building a corpus on a trend, or an agency assembling a dataset a client will pay for. All three hit the same wall on day one, and it is not the tool — it is that nobody has worked out where the million actually lives. The honest headline first: a seven-figure pull is possible, and it takes hours, not minutes. Instagram — not the exporter — sets that ceiling, and the reason most tools cannot do it at all is that they try to beat the ceiling instead of respecting it, and get their users rate-limited, action-blocked or banned. This guide covers the arithmetic, the batching, why it takes as long as it takes, what genuinely breaks at seven figures, and how to get the file into an AI model without a five-figure token bill.
A million comments is never one post
Start by killing the mental image. The largest Instagram posts in the world sit in the low millions of comments and they are K-pop and football accounts; your campaign post has four thousand. A million-row dataset is almost always n posts × a few thousand comments each: 40 posts at 25,000, or 300 posts at 3,300.
That matters because the job shape changes completely. One mega-post is a pagination endurance test. Three hundred normal posts is a scheduling problem — batches, a URL list, and stacking files — and scheduling problems are the ones that finish.
So the first question is not "which tool exports the most" but "which 300 URLs". Export the post list for the accounts involved rather than collecting links by hand; you get every public post URL with its caption, date and engagement counts, which doubles as the sampling frame for deciding which posts are worth pulling comments from at all.
Why it takes hours — and why that is the safe answer
Set the expectation before the invoice: a million Instagram comments is an afternoon or an overnight run, not a progress bar you watch. That is not a weakness of any particular exporter, it is Instagram. Comment threads are served in small paginated pages behind per-token and per-IP rate limits that tighten the deeper into a thread you go — Meta documents the mechanics in its platform rate limiting guide. There is no setting, no paid tier and no clever trick anywhere on the internet that makes Instagram hand over a million comments in ten minutes.
So the only real choice is what happens when you hit the limit. There are two behaviours, and they produce very different outcomes:
- Push through it. Hammer the endpoint, rotate crude proxies, run the requests through a logged-in session. You get speed for a while, then a hard stop: a 429 wall, a challenge page, an action block, and on session-based tools a restricted or banned account. Browser extensions and DIY scripts fail this way because they borrow your login — the block lands on you, not on the tool.
- Pace it. Back off on every rate-limit signal, spread the work, resume from the last cursor, and accept that the job takes hours. Nothing gets banned. The file arrives.
We built for the second behaviour, and that is the whole reason multi-hundred-thousand-row jobs finish here and stall elsewhere. Exports run server-side as queued jobs with backoff and resume, so the work continues while your laptop sleeps, no Instagram account of yours is involved at any point, and a rate limit is a pause rather than a failure. The honest limitation, stated plainly: we cannot make it fast, because nobody can. We can make it finish, and make it cost you nothing but time.
Two things this does not buy, because overclaiming here is how people lose accounts:
- Private accounts are permanently out of scope. No tool reaches them lawfully, and any tool offering to is asking for your credentials.
- Very large single posts can still be cut short. A thread in the hundreds of thousands may slow to the point that the practical answer is a capped pull plus a documented sample, not a complete census. We would rather say so up front than deliver a file with a silent hole in it.
Count everything before you pull anything
Every serious at-scale run starts with a counting pass. Paste each URL, read the counted total, write it into a sheet. The count is free, takes about a second per post, and it turns an open-ended job into a budget: total rows, how many batches, roughly how long.
The counting pass also exposes the distribution, which is usually brutal: in campaign datasets the top three posts routinely hold more comments than the remaining fifty combined. If 70% of your million sits in four posts, you need four careful exports and a sample of the tail, not 300 jobs — and you cannot see that without counts.
Batch sizes, caps and the shape of a run
Concrete numbers, because at-scale planning needs them. With ZocialComment: the first 100 comments of any post are free with no signup; a 3-Day Pass raises the per-post ceiling to 10,000 comments; the Pro passes raise it to 100,000 per post and add AI analysis. Posts per pass are unlimited, and bulk export takes up to 20 URLs per paste.
The run shape that works, and it is boring on purpose:
- Batches of 20. One paste, one job, one file, next. A batch that fails is 20 URLs to retry, not 300.
- Big posts alone. Anything over ~25,000 comments gets its own job. Mixing a 90,000-comment monster into a batch of small posts means the whole batch waits on it.
- Newest-first is the ordering. When a post exceeds your tier cap, you get the cap from the top of the thread, not a random sample. Know that before you write "complete dataset" in a client deck.
- Replies off unless you need them. Replies roughly double the row count on conversational posts and they are a different unit of analysis. Turn them on deliberately.
What actually breaks at seven figures
We operate the exporter daily, so this section is what we see, not what we imagine.
The badge gap gets blamed on the tool every single time. A post shows 48,000 comments, the export returns 43,100, and the first assumption is a broken exporter. The missing rows are hidden comments, keyword-filtered comments, comments awaiting review and comments from disabled accounts — counted in the badge, absent from the thread for every reader including Meta own API. Five to fifteen per cent is the normal band. At a million rows that is 50,000 to 150,000 comments that were never obtainable by anyone, and it needs to be in the methodology note before a client finds it themselves.
Time does not scale linearly. A 100,000-comment post is not ten times a 10,000-comment post, it is worse, because the deeper cursors are the rate-limited ones. Plan the big posts first in the day, not last, and expect the last 20% of a huge thread to take as long as the first 80%.
Spreadsheets die quietly. Excel hard-stops at 1,048,576 rows per sheet, as Microsoft documents in its specifications and limits, and it becomes unusable well below that. Past a few hundred thousand rows the answer is a database, DuckDB, or pandas — not a bigger laptop.
Encoding bites once. Instagram comments are heavily emoji and multi-script, so files must be UTF-8 with a byte-order mark for Excel to render Thai, Arabic or emoji correctly. Ours are written that way because the first version was not, and every support ticket that week was mojibake.
Stacking a million rows into one clean dataset
Thirty files become one dataset in about four lines of anything. The rules that keep it honest:
- Deduplicate on comment id, never on text. Two users writing "🔥🔥" are two real comments. The same id twice is an overlap between paginated pulls, which happens when a job is retried against a live thread.
- Keep a post_url column. Add it at stack time if the file does not carry one. Without it, per-post analysis is gone and cannot be reconstructed.
- Keep the raw JSON. CSV columns are the readable subset; the JSON has every field Instagram returned. The field you will need in November is one nobody ticked in September.
- Timestamp the pull. Comment threads change. A dataset without a collection date is not reproducible, and reviewers ask.
The columns you get by default — author, username, text, likes, replies, created_at, language, is_pinned, id, reply_to_id, avatar_url, plus every platform-specific field underneath — are enough for volume-over-time, per-author frequency, language mix, and engagement-weighted ranking without joining anything else in.
Feeding a million comments to an AI model
This is where most at-scale projects waste money. A million comments is roughly 30 to 60 million tokens of raw text. Sending that to any model is either impossible or absurd, and the output would be worse than a GROUP BY.
The pattern that works, in order:
- Aggregate first. Counts by post, by day, by language, by author. Top terms and bigrams. Engagement-weighted top comments. Most "what are people saying" questions are answered here, for free, in seconds.
- Cluster, do not read. Embed the comments, cluster the embeddings, and send the model the cluster centroids plus a handful of members each. A million comments collapses to 40 themes and a few thousand tokens.
- Sample stratified, not randomly. Sample within each cluster, each post and each language, so the minority themes that matter survive into the prompt.
- Send the model a question, not a corpus. "Which of these 40 themes indicate purchase intent, and which indicate a support failure" is a job an LLM does well. "Read these million rows" is not.
On the Pro passes the AI read is built in and follows the same pattern internally, which is why it stays cheap. If you are building your own pipeline, the embeddings documentation from any major provider covers the clustering step; the gap between "embed then summarise" and "paste everything" is typically two orders of magnitude of spend.
What we see running these jobs every day
We build and run ZocialComment, so the numbers here are the live product values — the 100-comment free cap, the 10,000 and 100,000 per-post ceilings, the 20-URL bulk paste, the exact column list — and not marketing rounding. The at-scale observations come from watching real jobs: the badge-versus-rows gap that generates most of our support mail, the deep-cursor slowdown on very large posts, the emoji encoding fix, and the repeated finding that the top three posts in a campaign hold most of the comments. Where the claim is about Instagram own rules rather than our tool, we link Meta documentation rather than paraphrasing it, because those rules change and our summary would not.
Compliance when the file is this big
A million usernames is a database of identifiable people, and volume is exactly what turns a casual export into a regulated one. The GDPR applies to a comment CSV the same way it applies to a customer list: have a purpose, keep it only as long as that purpose lives, restrict who can open it, and delete it when the campaign closes. Instagram Terms of Use restrict automated collection, so the defensible shape of this work is public posts, a documented research or measurement purpose, aggregate reporting rather than individual profiling, and no cold DM list mined out of the file. Research use has a further norm worth keeping: report themes and counts, not quoted comments attached to usernames.
Start small, then scale the same motion
Everything above is the same four clicks repeated: paste, count, export, stack. Run it once on a single post for free before planning a seven-figure pull — one real counting pass tells you more than any amount of planning.
Download Instagram comments free →
Related reading: bulk exporting Instagram comments, the Instagram comments API, honestly, the agency guide to Instagram comment export.