Instagram ban risk checker

Instagram, like every major platform fighting spam and bot networks, doesn't rely on a single signal to flag an account. It builds a composite trust score from dozens of device- and session-level attributes, and fingerprint mismatches are the fastest way to tank that score before a single automated action ever runs.

Automation frameworks announce themselves. Tools like Selenium, Puppeteer, and Playwright set a browser-level flag (navigator.webdriver) specifically so sites can detect them. It exists for legitimate QA testing — and it's also the single cheapest bot-detection check any platform can run, because it requires zero behavioral analysis at all.

Mismatches compound. One odd signal in isolation — say, a slightly unusual timezone — is noise. A device that reports a mobile user agent with zero touch points, a timezone that doesn't match its declared language, and desktop-class CPU core counts all at once stops looking like noise and starts looking like an emulator or a scripted browser session.

The app vs browser gap is structural, not cosmetic. Instagram is built mobile-first. The native app has access to dozens of hardware and OS-level signals (accelerometer, GPS, cell radio state, SIM presence, install provenance) that a browser session simply cannot produce — real or spoofed. That gap alone is why browser-based and emulator-based automation get capped at lower reach and stricter rate limits than the same activity performed through a real device running the real app.

navigator.webdriver (automation flag). True means an automation framework is actively controlling this browser session. This is the single highest-confidence bot signal available client-side — real users never trigger it.

User agent vs device class. A desktop user agent on a platform where legitimate traffic is overwhelmingly mobile isn't an instant ban, but it's treated as lower-trust — different rate limits, different reach ceiling.

Touch support vs claimed device type. A user agent string claiming to be an iPhone or Android device with zero reported touch points is internally inconsistent — a strong sign the UA was manually overridden rather than reflecting real hardware.

Hardware concurrency and memory. Real phones cluster in a predictable range of CPU core counts and RAM. A "phone" reporting workstation-class specs is consistent with an emulator or a cloud-hosted Android instance, not a handset in someone's pocket.

Timezone vs language/locale. Real accounts have a timezone and a language/locale that agree with each other and with the connecting IP's geolocation. A mismatch between any of the three is one of the oldest and most reliable proxy and VPN tells in the book.

Screen size sanity check. A session identifying as mobile with a desktop-monitor-sized screen usually means it originated from a browser's built-in mobile emulation mode — a common leftover from testing automation scripts that never touched real hardware.

Being honest about the limits matters more than a scary score. Two things this checker explicitly does not evaluate:

IP address type. Whether you're connecting from residential mobile data, a datacenter proxy, or a VPN exit node is arguably the single biggest ban-risk factor for automation — and it cannot be read from client-side JavaScript at all. A clean fingerprint score here says nothing about IP reputation.

A flagged signal isn't a verdict. Plenty of real users browse Instagram.com from a desktop browser every day without consequence. What actually moves risk is the combination and the account's behavior on top of it — this tool surfaces the raw signals, not a guarantee of what will happen to any specific account.

For the IP-side half of the picture, see the automation cost calculator and the full real phones vs emulators breakdown.

Every signal this tool checks exists because emulators, cloud phones, and browser automation have to simulate a real device. ShadowPhone doesn't simulate anything — it runs the actual Instagram app on actual Pixel hardware, so every signal is genuine by construction:

Real mobile user agent. Because it's the real Instagram Android app on a real Android build, not a spoofed string.

No automation framework, no webdriver flag. Actions run through Android's accessibility and input layers on physical hardware — there is no Selenium, Puppeteer, or Playwright process attached to the session for Instagram to detect.

Real touch hardware. A physical touchscreen registers real touch events with real hardware-level jitter and pressure characteristics — not synthesized clicks dressed up as taps.

Real GPS and timezone. The phone's system clock, locale, and location services reflect wherever the device physically sits, so timezone, language, and IP geolocation agree with each other by default instead of needing to be manually reconciled.

Real SIM and mobile-data IP. Traffic exits through actual mobile carrier infrastructure rather than a datacenter proxy or residential proxy pool — the exact IP-reputation category this browser-based tool can't measure, and the one that matters most.

None of this makes bad behavior safe — volume caps and human-plausible pacing still matter. It means the device layer stops being the reason an account gets flagged in the first place.