DEV Community

Cover image for Why Your Automation Keeps Getting Detected: A Developer’s Guide to Browser Fingerprinting
Multilogin
Multilogin

Posted on

Why Your Automation Keeps Getting Detected: A Developer’s Guide to Browser Fingerprinting

#automation #fingerprinting #privacy #webdev

If you've ever written automation for TikTok, Meta, Shopee, Zalo or any other platform in Vietnam, you have probably experienced this:

One day your script runs like butter. Next thing you know, every login, click, API call just fails: Without errors, without rate limits, mute bans.

That's not your proxy or cookie.

That's browser fingerprinting: the secret identity layer of the modern web.

What Browser Fingerprinting Actually Is

When a browser visits a site, it doesn’t just share its IP or cookies.
It leaks a set of parameters that make each session unique — almost like a digital DNA.

Here’s what most websites can collect instantly through JavaScript or HTTP headers:

{
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
  "language": "en-US",
  "timezone": "Asia/Ho_Chi_Minh",
  "screen": "1920x1080",
  "canvasHash": "b45e2a7d9a1",
  "webglVendor": "NVIDIA",
  "fonts": ["Roboto", "Arial"],
  "platform": "Win32",
  "hardwareConcurrency": 8
}
Enter fullscreen mode Exit fullscreen mode

Each of these values by itself is harmless — but combined, they form a unique fingerprint that can identify your browser even after IPs, cookies, or sessions change.

Why Fingerprinting Breaks Your Automation

The majority of automation frameworks — Selenium, Puppeteer, Playwright — still leak identical fingerprints when running multiple sessions.
So when your script opens ten browser windows with the same WebGL vendor, canvas hash and timezone, detection engines notice a pattern:

“Ten customers logged in from ten different IPs but using the identical browser settings. Fishy.”

Detection engines don’t require cookies to make the connection.
Which is why even basic scraping or multi-account activity can start getting flagged after a few iterations.

How Detection Systems Spot “Non-Human” Browsers

Here’s what real detection code looks for:

  • navigator.webdriver === true (a dead giveaway for headless browsers)
  • Missing or empty properties like plugins, mimeTypes, or deviceMemory
  • Identical Canvas and WebGL rendering outputs
  • Proxy-country mismatch with timezone (US proxy + Asia/Ho_Chi_Minh)
  • Too-fast interactions or identical pointer movements

Add a few of these together and your automation looks robotic even if your code is flawless.

Common Mistakes That Trigger Detection

  • Using headless mode – Headless Chromium adds obvious flags like navigator.webdriver, instantly exposing automation.
  • Randomizing everything on every run – If your browser identity changes completely every login, it looks like a new device each time.
  • - Ignoring regional consistency – Mixing proxies and timezones (e.g., a US proxy with a Vietnam timezone) doesn’t match normal user behavior.
  • - Copy-pasting browser profiles – Duplicated fingerprints are easily linked by detection systems.
  • - Sharing sessions across accounts – Reusing cookies or localStorage connects multiple identities together.

How to Fix It: Building Fingerprint-Resilient Automation

  1. Act Like a Real Device with Each Profile

Each account should have a stable, real fingerprint.
It should not be random, noisy data. Expectations for your browser's fingerprint should be:

  • Consistent OS version
  • Consistent fonts
  • Consistent hardware data
  1. Align your Timezone, Proxy, and Language

Region related data should match, such as:

Proxy: Japan
Timezone: Asia/Tokyo
Language: ja-JP
Enter fullscreen mode Exit fullscreen mode

Region data being out of sync with your proxy is one of the easiest signals to detect.

  1. Don't Run in True Headless Mode

Most websites and apps can instantly detect headless Chromium.
If necessary, switch to visible mode or use stealthified solutions like puppeteer-extra-plugin-stealth.

  1. Isolate Your Sessions

Cookies, Cache, LocalStorage, etc should be separate for each identity.
This can be done manually with the browser contexts API or tools built for exactly this purpose (see below).

Where Antidetect Browsers Fit In

Handling configuration and maintenance at scale can be a very painful process.

For large automation and testing teams, managing unique fingerprints by hand is no longer feasible.

This is where antidetect browsers shine.

These are browsers that:

  • automatically generate realistic, customizable fingerprints
  • tie each profile to its own IP, timezone and storage
  • eliminate cross-leakage between profiles
  • work with automation frameworks (Playwright, Puppeteer, Selenium) In short, they don’t make your automation “invisible” to services and websites. But they can make it appear like a real, consistent device.

Used in moderation, they enable legitimate multi-account use cases like testing localized websites or ad verification without getting banned all the time.

Here’s a simple baseline before you reach for heavier tooling:

import { chromium } from 'playwright';

async function createProfile(region, userAgent) {
  const browser = await chromium.launch({ headless: false });
  const context = await browser.newContext({
    locale: region.locale,
    timezoneId: region.timezone,
    userAgent: userAgent,
    viewport: { width: 1280, height: 720 }
  });
  const page = await context.newPage();
  await page.goto('https://pixelscan.net');
  await page.screenshot({ path: `${region.locale}.png` });
  await browser.close();
}

createProfile(
  { locale: 'vi-VN', timezone: 'Asia/Ho_Chi_Minh' },
  'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'
);
Enter fullscreen mode Exit fullscreen mode

This simple script emulates a “Vietnamese” browsing environment — language, timezone, and screen size included.
Antidetect browsers like Multilogin automate this logic at scale while preserving separate storage and cookies per profile.

The Responsible Use of Fingerprint Control

Fingerprint control is not about evasion, it’s about accuracy and stability.
Developers use these methods for these legitimate reasons:

  • Testing localized e-commerce experiences
  • Validating ads in different regions
  • Protecting user privacy by minimizing unnecessary tracking
  • Handling legitimate business accounts on behalf of clients
  • Responsible use: never to deceive users or to violate platform terms.

Key Takeaways

  • Browser fingerprinting = the invisible identity layer of the web.
  • IPs and cookies aren’t enough — your hardware and rendering data link sessions.
  • Randomizing fingerprints isn’t safe; consistency per profile is key.
  • Antidetect browsers and isolated profiles help scale safely when used ethically. If your automation keeps getting detected, fix the browser identity, not just the proxy.

Top comments (0)