DEV Community: chloe chen

Building a Browser-Based Instagram DM Automation System: Architecture, Security, and Practical Workflow published: true

chloe chen — Tue, 16 Jun 2026 02:44:21 +0000

TL;DR: Most Instagram DM automation tools ask for your password and run from their own servers — a bad trade. This post breaks down why browser extension-based automation is architecturally safer, how it works under the hood, and how to build a practical DM outreach workflow using IG DM as the execution layer.

The Problem With How Most DM Automation Works

If you've ever looked into automating Instagram direct messages, you've probably noticed that almost every tool on the market asks for the same thing upfront: your Instagram username and password.

You hand them over, the service logs into your account from their servers, and the automation runs. Simple from a UX perspective. Architecturally, it's a disaster.

Here's what's actually happening:

[You] → (credentials) → [Third-party Server]
                                ↓
                    Logs into Instagram from:
                    - Unknown IP address
                    - Unknown device fingerprint
                    - Unknown behavioral pattern
                                ↓
                        [Instagram's servers]

Instagram runs anomaly detection on all of this. Logins from unfamiliar IPs, device fingerprints that don't match prior session history, behavioral patterns that look nothing like a real user — all of these are signals that get flagged.

The result: temporary restrictions, feature locks, or in persistent cases, permanent account limitations.

Beyond the platform risk, there's the more obvious security concern: you've handed your credentials to a third party whose security practices you have no visibility into.

There's a better architectural approach.

Browser Extension Architecture: Why It's Different

A Chrome extension running automation within your existing browser session operates on fundamentally different principles.

[Your Chrome Browser]
├── Your Instagram session (already authenticated)
│     └── Content script injected by extension
│           ├── Reads DOM to identify targets
│           ├── Simulates user interactions
│           └── Manages state locally
└── Background service worker
      └── Handles scheduling and rate management

From Instagram's detection systems, this looks identical to you sitting at your computer doing things manually. Because technically, it is — same IP, same device fingerprint, same session token, same browser environment.

No credentials leave your machine. No external server is involved. The extension operates within the sandbox of your authenticated session.

Let's look at the core mechanisms.

How Content Script Automation Actually Works

When a Chrome extension injects a content script into an Instagram tab, it gets access to the page's DOM with the same permissions as the page itself. This is what makes browser-based automation structurally sound.

Spin Syntax Processing

One of the most important pieces of any DM automation system is message variation. Sending identical messages at scale is both detectable and ineffective. Here's a simple spin syntax processor:

/**
 * Processes spin syntax templates to generate varied messages
 * Syntax: {option1|option2|option3}
 * 
 * @param {string} template - Message template with spin syntax
 * @returns {string} - Processed message with random selections
 */
function processSpinSyntax(template) {
  return template.replace(/\{([^{}]+)\}/g, (match, group) => {
    const options = group.split('|');
    const selectedIndex = Math.floor(Math.random() * options.length);
    return options[selectedIndex].trim();
  });
}

// Example usage
const template = `{Hey|Hi|Hello} — {noticed you just followed|saw you found the account}.
{We cover|The account focuses on} {[topic] strategy|practical [topic] guides}.
{Worth checking out|Might be useful} if {[topic] is relevant to what you're working on|you're into [topic]}.`;

// Each call produces a different variation
console.log(processSpinSyntax(template));
// → "Hi — saw you found the account.
//    The account focuses on practical [topic] guides.
//    Might be useful if you're into [topic]."

console.log(processSpinSyntax(template));
// → "Hello — noticed you just followed.
//    We cover [topic] strategy.
//    Worth checking out if [topic] is relevant to what you're working on."

With 3 options per placeholder and 5 placeholders, you get 3^5 = 243 unique message combinations from a single template.

Rate-Limiting Logic

Sending too fast is the most common cause of account restrictions. A well-designed rate limiter needs to account for account age, recent send volume, and time distribution:

class RateLimiter {
  constructor(options = {}) {
    this.dailyLimit = options.dailyLimit || 60;
    this.accountAgeMonths = options.accountAgeMonths || 6;
    this.sentToday = 0;
    this.sentHistory = new Set(); // For deduplication
    this.sessionStart = Date.now();
  }

  /**
   * Calculate safe interval between sends
   * Returns milliseconds to wait
   */
  getSafeInterval() {
    let minMs = 45_000;  // 45 seconds minimum
    let maxMs = 90_000;  // 90 seconds maximum

    // New accounts need more conservative pacing
    if (this.accountAgeMonths < 3) {
      minMs = 90_000;
      maxMs = 180_000;
    }

    // As daily limit approaches, increase spacing
    const utilizationRate = this.sentToday / this.dailyLimit;
    if (utilizationRate > 0.7) {
      minMs *= 1.5;
      maxMs *= 1.5;
    }

    // Add jitter to avoid predictable patterns
    const jitter = Math.random() * (maxMs - minMs);
    return Math.floor(minMs + jitter);
  }

  canSendTo(userId) {
    if (this.sentToday >= this.dailyLimit) {
      console.log(`Daily limit (${this.dailyLimit}) reached`);
      return false;
    }
    if (this.sentHistory.has(userId)) {
      console.log(`Skipping ${userId}: already contacted`);
      return false;
    }
    return true;
  }

  recordSend(userId) {
    this.sentHistory.add(userId);
    this.sentToday++;
  }

  getStatus() {
    const elapsed = (Date.now() - this.sessionStart) / 1000 / 60;
    return {
      sent: this.sentToday,
      remaining: this.dailyLimit - this.sentToday,
      utilization: `${((this.sentToday / this.dailyLimit) * 100).toFixed(1)}%`,
      sessionMinutes: elapsed.toFixed(1),
      avgSendRate: this.sentToday / (elapsed || 1)
    };
  }
}

The Send Loop

Putting it together into a send loop that respects rate limits and handles deduplication:

async function runDMCampaign(targetUsers, messageTemplate, limiter) {
  const results = {
    attempted: 0,
    sent: 0,
    skipped: 0,
    errors: 0
  };

  console.log(`Starting campaign: ${targetUsers.length} targets`);

  for (const user of targetUsers) {
    results.attempted++;

    // Check if we can send to this user
    if (!limiter.canSendTo(user.id)) {
      results.skipped++;
      continue;
    }

    // Check daily limit
    if (limiter.sentToday >= limiter.dailyLimit) {
      console.log('Daily limit reached. Stopping campaign.');
      break;
    }

    try {
      // Generate unique message for this recipient
      const message = processSpinSyntax(messageTemplate);

      // Send the DM (implementation depends on page DOM)
      await sendDirectMessage(user.username, message);

      // Record the send
      limiter.recordSend(user.id);
      results.sent++;

      console.log(`✓ Sent to @${user.username} | ${limiter.getStatus().sent}/${limiter.dailyLimit}`);

      // Wait before next send
      const waitTime = limiter.getSafeInterval();
      console.log(`Waiting ${(waitTime / 1000).toFixed(0)}s before next send...`);
      await sleep(waitTime);

    } catch (error) {
      results.errors++;
      console.error(`✗ Failed for @${user.username}:`, error.message);

      // On error, wait longer before retrying
      await sleep(120_000); // 2 minute cooldown on error
    }
  }

  console.log('Campaign complete:', results);
  return results;
}

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

The Tool: IG DM in Practice

Rather than building the full extension from scratch (which would require Chrome extension packaging, DOM interaction logic for Instagram's frequently-updated UI, and persistent state management), IG DM implements this architecture as a ready-to-use Chrome extension.

The core capabilities map directly to the concepts above:

Capability	Under the Hood
New follower auto-DM	Real-time DOM polling for follower changes
Post liker campaigns	Extracts user list from post engagement data
Commenter campaigns	Parses comment thread DOM
Custom user lists	Accepts comma-separated usernames as input
Spin syntax	Processes `{A\
Deduplication	Maintains session-persistent sent-user registry
Progress tracking	Live counter updated via DOM manipulation

Setup is intentionally minimal:
{% raw %}

1. Install from Chrome Web Store
2. Log into Instagram in Chrome (as normal)
3. Open the extension
4. Configure your message template and target type
5. Hit Start

No API keys. No OAuth flows. No credential forms. The extension operates within your existing authenticated session.

Audience Prioritization: Who to Message and When

Not all outreach targets are equivalent. Here's how to think about priority ordering:

// Audience tier configuration
const AUDIENCE_TIERS = {
  TIER_1: {
    types: ['post_commenters', 'post_likers_recent'],
    recencyWindow: 72 * 60 * 60 * 1000, // 72 hours in ms
    expectedReplyRate: 0.20,              // ~20%
    description: 'Recent engagers — highest intent signal',
    dailyAllocation: 0.40                 // 40% of daily budget
  },
  TIER_2: {
    types: ['new_followers'],
    recencyWindow: 24 * 60 * 60 * 1000, // 24 hours
    expectedReplyRate: 0.12,
    description: 'New followers within 24h — time-sensitive',
    dailyAllocation: 0.35
  },
  TIER_3: {
    types: ['custom_list_warm'],
    recencyWindow: null,                  // No recency constraint
    expectedReplyRate: 0.18,
    description: 'Warm custom lists — prior relationship exists',
    dailyAllocation: 0.15
  },
  TIER_4: {
    types: ['competitor_followers'],
    recencyWindow: null,
    expectedReplyRate: 0.05,
    description: 'Cold outreach — use sparingly',
    dailyAllocation: 0.10
  }
};

function calculateDailyBudgetAllocation(totalDailyLimit) {
  return Object.entries(AUDIENCE_TIERS).reduce((acc, [tier, config]) => {
    acc[tier] = {
      ...config,
      dailyCount: Math.floor(totalDailyLimit * config.dailyAllocation)
    };
    return acc;
  }, {});
}

// Example output for daily limit of 80
const allocation = calculateDailyBudgetAllocation(80);
console.table(
  Object.entries(allocation).map(([tier, data]) => ({
    Tier: tier,
    Type: data.types.join(', '),
    'Daily Count': data.dailyCount,
    'Expected Reply Rate': `${(data.expectedReplyRate * 100).toFixed(0)}%`
  }))
);

/*
┌────────┬─────────────────────────┬─────────────┬──────────────────────┐
│ Tier   │ Type                    │ Daily Count │ Expected Reply Rate  │
├────────┼─────────────────────────┼─────────────┼──────────────────────┤
│ TIER_1 │ post_commenters, likers │ 32          │ 20%                  │
│ TIER_2 │ new_followers           │ 28          │ 12%                  │
│ TIER_3 │ custom_list_warm        │ 12          │ 18%                  │
│ TIER_4 │ competitor_followers    │  8          │  5%                  │
└────────┴─────────────────────────┴─────────────┴──────────────────────┘
*/

Message Template Design: What Actually Converts

The architecture is table stakes. The message quality is what determines outcomes.

Here are the structural patterns that consistently produce higher reply rates:

Pattern 1: The Context Bridge

Reference the specific action that prompted the message. This is the most important structural element.

// ✅ Context bridge — tells recipient why they're receiving this
const contextBridgeTemplate = `{Hey|Hi} — {noticed|saw} you {just followed|found the account} after {the|our} post on [topic].

That piece actually has a longer version I wrote up recently — {covers|goes into} the part {most people want to dig into|that tends to generate the most questions}.

{Want me to send it?|Happy to share if it's useful.}`;

// ❌ No context — recipient has no idea why they're being contacted
const noContextTemplate = `Hey! Thanks for following! Check out our latest content at [link] 🎉`;

Pattern 2: The Single Value Offer

One thing. Not three things. Not a menu.

// ✅ Single clear offer
const singleOfferTemplate = `{Hi|Hey} — saw you liked the post on [topic].

I wrote a longer breakdown on that exact problem last week — {more tactical|goes further than the original}.

{Link if you want it?|Happy to drop the link here.}`;

// ❌ Multiple competing asks
const multipleAsksTemplate = `Hi! We have a newsletter, a free guide, a webinar next week, 
and a special offer for new followers. Check them all out!`;

Pattern 3: The Pressure-Free Close

Giving recipients an explicit out paradoxically increases reply rates.

// Template variants for the close
const pressureFreecloses = [
  "No worries if not — just thought it might be relevant.",
  "Happy to share if it's useful, no pressure either way.",
  "Only worth looking at if [topic] is relevant to what you're working on.",
  "Let me know if it's something you'd find useful.",
];

// The phrase "no pressure" or "no worries if not" signals 
// that you're not running a hard sell sequence.
// This is the difference between outreach that feels like 
// a conversation and outreach that feels like a funnel.

Measuring What Matters

class CampaignTracker {
  constructor(campaignId, audienceTier) {
    this.campaignId = campaignId;
    this.audienceTier = audienceTier;
    this.metrics = {
      sent: 0,
      replies: 0,
      positiveReplies: 0,
      negativeReplies: 0,        // "Please don't message me"
      conversationsContinued: 0, // 2+ exchanges
      deepConversations: 0,      // 3+ exchanges
      conversions: 0,
    };
    this.startTime = Date.now();
  }

  record(event) {
    if (this.metrics.hasOwnProperty(event)) {
      this.metrics[event]++;
    }
  }

  getKPIs() {
    const { sent, replies, positiveReplies, negativeReplies,
            conversationsContinued, conversions } = this.metrics;

    if (sent === 0) return null;

    return {
      replyRate:            (replies / sent).toFixed(3),
      positiveReplyRate:    (positiveReplies / sent).toFixed(3),
      negativeRate:         (negativeReplies / sent).toFixed(3),
      conversationRate:     (conversationsContinued / Math.max(replies, 1)).toFixed(3),
      conversionRate:       (conversions / sent).toFixed(3),
      replyToConversion:    (conversions / Math.max(replies, 1)).toFixed(3),
    };
  }

  shouldAlert() {
    const kpis = this.getKPIs();
    if (!kpis) return null;

    const alerts = [];
    if (parseFloat(kpis.negativeRate) > 0.02) {
      alerts.push(`⚠️ Negative reply rate (${kpis.negativeRate}) exceeds 2% — review targeting`);
    }
    if (parseFloat(kpis.replyRate) < 0.08) {
      alerts.push(`📉 Reply rate (${kpis.replyRate}) below 8% — review message copy`);
    }
    return alerts.length > 0 ? alerts : null;
  }

  printReport() {
    const kpis = this.getKPIs();
    const runtime = ((Date.now() - this.startTime) / 1000 / 60).toFixed(1);

    console.log(`\n${'─'.repeat(50)}`);
    console.log(`Campaign: ${this.campaignId} | Tier: ${this.audienceTier}`);
    console.log(`Runtime: ${runtime} minutes`);
    console.log(`${'─'.repeat(50)}`);
    console.log(`Sent:               ${this.metrics.sent}`);
    console.log(`Reply Rate:         ${(parseFloat(kpis.replyRate) * 100).toFixed(1)}%`);
    console.log(`Negative Rate:      ${(parseFloat(kpis.negativeRate) * 100).toFixed(1)}%`);
    console.log(`Conversation Rate:  ${(parseFloat(kpis.conversationRate) * 100).toFixed(1)}%`);
    console.log(`Conversion Rate:    ${(parseFloat(kpis.conversionRate) * 100).toFixed(1)}%`);

    const alerts = this.shouldAlert();
    if (alerts) {
      console.log(`\nAlerts:`);
      alerts.forEach(alert => console.log(`  ${alert}`));
    }
  }
}

Benchmark targets by audience tier:

Metric	Tier 1 Target	Tier 2 Target	Alert Threshold
Reply Rate	≥ 18%	≥ 10%	< 8%
Negative Rate	< 0.5%	< 1%	> 2%
Conversation Rate	≥ 40%	≥ 25%	< 15%
Conversion Rate	≥ 5%	≥ 2%	< 1%

Common Failure Modes

Failure 1: Treating volume as the primary variable

More sends with a weak message produces worse outcomes than fewer sends with a strong one, and generates more account risk. Fix the message first. Scale second.

Failure 2: Cold outreach at Tier 1 volume

Competitor follower lists (Tier 4) should never receive the daily send volume you allocate to post commenters (Tier 1). The risk profile and expected performance are completely different. Mixing them destroys your average metrics and misattributes campaign performance.

Failure 3: Static templates

A template that performed well in week 1 won't perform the same in week 6. Review and refresh message variants monthly. Add new spin syntax combinations. Retire underperforming patterns.

Failure 4: Ignoring the replies

Automation handles initiation. If you're not manually managing the conversations that result, you've built a lead generation machine and unplugged the follow-up. Block 20–30 minutes each morning to continue active DM threads.

Failure 5: Post-restriction overcorrection

If you hit a rate limit, the instinct is to wait briefly and then send harder to make up for lost time. This reliably makes things worse. Follow the restart protocol:

Restriction detected
        ↓
Full stop — no sends for 48–72 hours
        ↓
Resume at 30% of prior daily volume
        ↓
Increase by ~15% per week until back to target
        ↓
Do not attempt to compensate for missed volume

The Architecture Decision That Changes Everything

Let me be direct about why the extension architecture matters beyond the obvious security point.

When you use a server-based tool, you're operating in a context that Instagram's systems are explicitly designed to detect. The whole threat model of automated account access assumes an external service logging in from non-native infrastructure. Every SaaS-based Instagram tool exists in tension with this detection layer.

When you use a browser extension operating within your own session, you're not working around this detection — you're simply outside its scope. The activity is indistinguishable from normal user behavior because it fundamentally is normal user behavior, executed with programmatic timing.

This architectural distinction matters operationally. In practice, it means:

No credential exposure risk
No anomalous IP detection
No device fingerprint mismatch
Consistent behavioral patterns that match your normal usage

IG DM is built on this model. It's why browser extension-based DM automation is structurally sounder than SaaS alternatives, not just in theory but in day-to-day operational reliability.

Quick Implementation Checklist

# Week 1: Foundation
☐ Install IG DM extension from Chrome Web Store
☐ Configure new-follower auto-DM with 3+ message variants
☐ Set daily limit appropriate for account age:
    <3 months  → 20 sends/day
    3-12 months → 50 sends/day  
    1+ years    → 80 sends/day
☐ Enable deduplication
☐ Start tracking: reply rate baseline

# Week 2: Message Optimization  
☐ Add spin syntax to all templates (minimum 8 combinations)
☐ Write Tier 1 campaign message (post likers/commenters)
☐ A/B test two message variants
☐ Review first-week reply data

# Week 3-4: Scale
☐ Launch post-engagement campaigns (Tier 1 audience)
☐ Increase volume by 10-15 sends/day per week
☐ Set up campaign tracking spreadsheet
☐ Block 20min/day for manual reply management

# Monthly
☐ Audit all message templates
☐ Retire lowest-performing variants
☐ Write 2-3 new variants based on reply patterns
☐ Review send volume vs. account health metrics

Wrapping Up

The core insight here is architectural: browser extension-based automation isn't just a safer implementation — it's a different threat model entirely. You're not trying to circumvent Instagram's detection systems; you're operating within the normal bounds of authenticated user behavior.

The practical workflow is straightforward:

Target warm audiences first (commenters > likers > new followers > cold)
Design messages that reference specific engagement context
Pace sends conservatively and consistently
Treat automation as initiation infrastructure, not a replacement for real conversation

The technical pieces — spin syntax, rate limiting, deduplication, campaign tracking — are all solvable engineering problems. The harder problem is message quality, which no tool can automate.

Have questions about the implementation or the architecture trade-offs? Drop them in the comments — happy to dig into specifics.

Tags: #javascript #automation #marketing #webdev

I Got Tired of Manually Copying Instagram Comments Into Spreadsheets. Here's What I Use Instead.

chloe chen — Tue, 09 Jun 2026 02:37:07 +0000

Let me describe a workflow I used to have.
Open Instagram post. Scroll to comments. Copy comment text. Switch to spreadsheet. Paste. Note the username. Go back. Scroll down. Repeat. For two hours.
I was doing this to collect comment data for a side project — basic NLP work, sentiment tagging, nothing fancy. Just needed the text in a CSV. It was the most boring two hours I'd spent in front of a computer in a long time, and I knew somewhere in the back of my mind that this was a solved problem I just hadn't looked up yet.
So I looked it up.

**The Actual Problem

Instagram has no public API for comment extraction. This is the source of most of the pain.
If you've tried to build around this with Python, you know the drill: requests gets you blocked almost immediately. Selenium works briefly before Instagram's bot detection catches on. The headless browser detection Instagram runs looks at TLS fingerprints, JavaScript execution context, request interval regularity — stuff that's hard to spoof convincingly at the client layer without significant ongoing maintenance.
The detection isn't looking for "are you using requests" — it's looking for behavioral and fingerprint signals that distinguish real browser sessions from simulated ones. That distinction matters for how you think about solving the problem.

Why a Browser Extension Is Architecturally Interesting Here
A Chrome extension runs inside a real browser process. Not a headless simulation, not a Python session pretending to be a browser — an actual Chrome instance with real:

User-Agent strings
TLS fingerprints
Cookie and session context
JavaScript execution environment

From Instagram's infrastructure perspective, traffic from a Chrome extension is structurally identical to traffic from a person manually scrolling through comments. There's nothing to detect because there's nothing being faked.
This is the core reason browser-based collection is more reliable for this specific use case than server-side approaches. It's not cleverer bot evasion — it's just not triggering the detection in the first place.
The secondary property worth noting: everything runs locally. The data goes from Instagram's servers directly to your machine. No intermediate server, no third-party database, no data leaving your browser environment. For any project handling user data or working under privacy constraints, that architecture is meaningfully better than cloud-based alternatives.

**The Tool
The extension I landed on is Instagram Comments Scraper.
The workflow is about as minimal as it gets:

Click extension icon in Chrome toolbar

Click "Export Instagram Data" → opens option page

Paste the Instagram post URL

Click "Start Parsing"

Download CSV or Excel when complete

Output structure per row:

id | unique comment identifier
text | full comment text
username | commenter's handle
profile_url | link to their profile
profile_pic_url| avatar URL
date | timestamp
Clean enough to load directly into pandas without any preprocessing:
pythonimport pandas as pd

df = pd.read_csv('instagram_comments.csv')

Immediate usability

print(df.shape)
print(df['text'].head(10))

Basic frequency pass

from collections import Counter
import re

words = []
for comment in df['text'].dropna():
words.extend(re.findall(r'\b\w+\b', comment.lower()))

print(Counter(words).most_common(20))

**Rate Limit Handling — The Part Worth Looking At
**Instagram rate-limits comment loading. The thresholds aren't documented and vary by IP. Any tool that ignores this will fail on large posts.
The extension handles it with what amounts to adaptive exponential backoff:
Normal Mode
→ rate limit detected
Cooldown Mode (countdown timer displayed, no requests sent)
→ timer expires, retry
├── success → back to Normal Mode
└── failure → cooldown period × 2 → repeat

This is the same pattern you'd implement if you were building against any undocumented API with dynamic rate limits. The doubling cooldown matters because fixed-wait approaches fail when the restriction window is longer than your fixed interval. Exponential backoff converges regardless of where the actual limit sits.
Practically: you can start a collection job on a post with several thousand comments, minimize the browser, and come back to a completed file. No babysitting, no manual restarts, no incomplete datasets.

**What I Actually Did With the Data
For my use case — basic sentiment analysis on a niche topic — the workflow after export was:
pythonimport pandas as pd
from textblob import TextBlob

df = pd.read_csv('instagram_comments.csv')
df = df.dropna(subset=['text'])

Quick sentiment pass

df['polarity'] = df['text'].apply(
lambda x: TextBlob(str(x)).sentiment.polarity
)
df['sentiment'] = pd.cut(
df['polarity'],
bins=[-1, -0.1, 0.1, 1],
labels=['negative', 'neutral', 'positive']
)

print(df['sentiment'].value_counts())
print(df.groupby('sentiment')['text'].head(3))
Not production NLP. But for a side project where I just needed to understand the rough distribution of responses to a specific post, it was more than sufficient — and the data collection that would have taken hours took about four minutes.

Limitations Worth Being Honest About
Chrome only. Chromium-based browsers work. Firefox doesn't.
Volume ceiling. Posts with 50k+ comments will finish, but the rate limit cooldowns add up. Large jobs are better left running overnight.
Frontend dependency. Like any tool that doesn't use an official API, it depends on Instagram's current HTML structure. Instagram updates its frontend; the extension may need updates in response. This is a shared limitation of every non-API approach.
Public posts only. Private account content is inaccessible. Expected behavior, but worth stating.

When This Is and Isn't the Right Tool
Good fit:

Side projects and personal research
One-off data collection tasks
Small team audience analysis without enterprise budget
Influencer evaluation before a campaign
Quick competitive comment audits

Not the right fit:

Production data pipelines that need to run on a schedule
Multi-account or multi-post parallel collection at scale
Teams that need API-level reliability guarantees

For anything in the second list, you're looking at a proper scraping infrastructure with proxy rotation, or paying for a social data API. The extension fills the space below that threshold — and that space is where most individual developers and small teams actually live.

One Other Thing
The extension doesn't ask for your Instagram password. It doesn't access your account, your feed, your DMs, or anything connected to your profile. It reads public comment data from the URL you provide and nothing else.
I checked this the obvious way — opened DevTools Network tab, watched the traffic while it ran. No outbound requests to any third-party endpoint. Everything stays local.
For a tool interacting with a social platform, that's worth verifying before you install it.

Anyway. That's the tool. If you're doing any kind of Instagram data work and still copying things by hand, there's a better option. The Instagram Comments Scraper extension has been reliable for what I needed — hopefully it's useful for someone else's project too.
Happy to discuss the rate limit handling approach or alternative architectures for this problem in the comments if anyone's interested.