Antidetect Browsers With Fingerprint Protection (2026)

A detection vendor does not compute one fingerprint. It collects a few dozen values, hashes some of them, and looks for two things: a hash it has seen before on a different account, and a set of values that cannot physically coexist on one machine. Five surfaces carry most of the weight.

The first four are JavaScript-visible, so every vendor competes there and most of them are competent. The fifth is where products quietly differ, because no settings panel can reach it.

A canvas probe draws text, an emoji, and a gradient into an offscreen canvas, reads the pixels back, and hashes them. The result varies with GPU, driver version, anti-aliasing, and the platform font rasterizer, which is what makes it useful for tracking. Three strategies exist and they are not equally good.

Blocking

Return an empty canvas or a constant. This defeats the hash and creates a worse problem: a blank canvas is rarer than any real one. Tor Browser handles this by prompting the user, which is a deliberate choice for a browser whose users all want to look identical. An antidetect profile that wants to look like one specific ordinary person should never block.

Per-read noise

Perturb the low bits of the pixel data every time getImageData runs. This breaks naive hashing and produces a different value on every call. A detector that reads the canvas twice in a single page load and gets two answers has learned something far more interesting than your canvas hash: it has learned you are running a masking tool. CreepJS does exactly this repeat-read check and reports the result as lies.

Seeded per-profile noise

Apply a deterministic perturbation from a PRNG seeded on the profile identifier. Same profile, same hash, forever. Different profile, different hash. This is the only one of the three that reproduces the behaviour of real hardware, and it is what you should be testing for.

// Paste into the console of the profile you are testing.
// Call it twice. Per-read noise gives you two different strings.
function canvasProbe() {
  const c = document.createElement('canvas');
  c.width = 280; c.height = 60;
  const ctx = c.getContext('2d');
  ctx.textBaseline = 'top';
  ctx.font = '16px "Arial"';
  ctx.fillStyle = '#f60';
  ctx.fillRect(0, 0, 120, 30);
  ctx.fillStyle = '#069';
  ctx.fillText('SparkProxy fingerprint probe \u{1F512}', 2, 15);
  const viaUrl = c.toDataURL().slice(-48);
  const px = ctx.getImageData(0, 0, c.width, c.height).data;
  let viaPixels = 0;
  for (let i = 0; i < px.length; i += 97) viaPixels = (viaPixels + px[i] * 31) % 1e9;
  return { viaUrl, viaPixels };
}
console.log(canvasProbe());
console.log(canvasProbe());

Read both paths, not one. Some implementations patch toDataURL and forget getImageData, or the reverse, and a probe that reads pixels directly then sails straight past the protection.

There is a cheaper tell than any of this. Ask the patched function to describe itself.

console.log(HTMLCanvasElement.prototype.toDataURL.toString());
console.log(WebGLRenderingContext.prototype.getParameter.toString());
console.log(Object.getOwnPropertyDescriptor(Navigator.prototype, 'hardwareConcurrency').get.toString());

Every one of those must print function name() { [native code] }. If you see actual JavaScript, the tool is patching from an injected script or an extension and the site can read the patch. Tools that modify the browser core in C++ pass this without effort. Tools that inject at document start have to also patch Function.prototype.toString, then patch the patch, and the recursion has to terminate somewhere visible.

WebGL exposes two kinds of information: identity strings, and a large set of capability numbers plus the rendered image itself. Vendors compete on the first and frequently ignore the second.

const gl = document.createElement('canvas').getContext('webgl');
const dbg = gl.getExtension('WEBGL_debug_renderer_info');
console.log({
  vendor: dbg && gl.getParameter(dbg.UNMASKED_VENDOR_WEBGL),     // 0x9245
  renderer: dbg && gl.getParameter(dbg.UNMASKED_RENDERER_WEBGL), // 0x9246
  maxTexture: gl.getParameter(gl.MAX_TEXTURE_SIZE),
  maxVarying: gl.getParameter(gl.MAX_VARYING_VECTORS),
  maxViewport: gl.getParameter(gl.MAX_VIEWPORT_DIMS),
  aliasedLine: gl.getParameter(gl.ALIASED_LINE_WIDTH_RANGE),
  highFloat: gl.getShaderPrecisionFormat(gl.FRAGMENT_SHADER, gl.HIGH_FLOAT).precision,
  extCount: gl.getSupportedExtensions().length,
  platform: navigator.platform
});

Run that in your profile and read it the way a detector would. A renderer string of ANGLE (Apple, ANGLE Metal Renderer: Apple M2, Unspecified Version) sitting next to a navigator.platform of Win32 is not a fingerprint, it is a confession. So is an Apple renderer paired with an extension list and a MAX_TEXTURE_SIZE that belong to Mesa on Linux. Anyone maintaining a lookup table keyed on renderer string, holding the expected tuple of capability values, catches that with a single query. Building the table takes an afternoon.

Two strings are worth watching for on their own. Google SwiftShader means software rendering, which on a desktop-class profile reads as a headless container. llvmpipe means the same thing on Linux. Both are common on cheap VPS hosts and both are strong bot signals independent of everything else the profile says. See headless browser detection for the rest of that family.

The rendered image matters too. A site can draw a shaded scene, call readPixels, and hash the result. Spoofing the identity strings does nothing to that hash unless the tool also perturbs the pixel output, deterministically, per profile.

AudioContext

The standard probe builds an offline audio graph, runs an oscillator through a dynamics compressor, renders it, and sums a slice of the output buffer. The result depends on the platform audio stack and on floating point behaviour, which makes it stable per machine and varied across machines.

async function audioProbe() {
  const ctx = new OfflineAudioContext(1, 44100, 44100);
  const osc = ctx.createOscillator();
  osc.type = 'triangle';
  osc.frequency.value = 10000;
  const comp = ctx.createDynamicsCompressor();
  comp.threshold.value = -50; comp.knee.value = 40; comp.ratio.value = 12;
  comp.attack.value = 0; comp.release.value = 0.25;
  osc.connect(comp); comp.connect(ctx.destination);
  osc.start(0);
  const buf = await ctx.startRendering();
  const data = buf.getChannelData(0);
  let sum = 0;
  for (let i = 4500; i < 5000; i++) sum += Math.abs(data[i]);
  return sum;
}
audioProbe().then(v => console.log(v.toFixed(12)));

Two conditions, and both matter. Within one profile the value must not move between calls or between launches. Across two profiles on the same tool it must differ. A tool that applies one fixed multiplier to every profile it creates has handed the detector a cluster key: every account you run through it shares an audio value that no unmodified machine produces.

Fonts

Sites rarely ask for a font list. They measure. Render a fixed string in a candidate family with a known fallback, compare offsetWidth and offsetHeight against the fallback rendering, and if the box changed size the font is installed.

function hasFont(name) {
  const base = 'monospace';
  const span = document.createElement('span');
  span.style.cssText = 'position:absolute;left:-9999px;font-size:72px;white-space:nowrap';
  span.textContent = 'mmmmmmmmmmlli';
  span.style.fontFamily = base;
  document.body.appendChild(span);
  const w0 = span.offsetWidth, h0 = span.offsetHeight;
  span.style.fontFamily = '"' + name + '",' + base;
  const changed = span.offsetWidth !== w0 || span.offsetHeight !== h0;
  span.remove();
  return changed;
}
console.log(['Segoe UI', 'Helvetica Neue', 'Ubuntu', 'Tahoma', 'Menlo', 'Calibri'].filter(hasFont));

Compare that output against the operating system your profile claims. A macOS profile reporting Segoe UI and Calibri is running on Windows and saying otherwise. A Windows profile with Menlo and Helvetica Neue but no Tahoma has the same problem in reverse. Some tools patch document.fonts.check() and Chrome's queryLocalFonts() while leaving the measurement path telling the truth, which is the worst of both worlds because the two answers now disagree with each other. Test both paths.

Related probes read getBoundingClientRect on styled elements, which picks up sub-pixel differences from the text rasterizer. If your tool offers a ClientRects setting, it should be on and it should be seeded per profile like everything else.

Everything above happens after the page loads. The handshake happens before it, and no checkbox in an antidetect browser reaches down that far.

The TLS ClientHello carries the version list, cipher suites, extensions, elliptic curves, and signature algorithms in an order characteristic of the client library. JA3 hashes that tuple. JA4 refines it, which mattered once Chrome began randomizing extension order and made a lot of JA3 databases stale. HTTP/2 adds a second layer: the SETTINGS frame values, the WINDOW_UPDATE increment, the pseudo-header order, and the priority tree, which together form what most people call the Akamai h2 fingerprint. Our TLS fingerprinting explainer walks through the calculation.

The consequence for antidetect browsers is blunt. A Chromium-derived browser produces a Chromium-shaped handshake. Setting the profile's user agent to Safari on macOS does not change one byte of it. The site now holds a JA4 that says Chromium and a UA string that says Safari, and it got there without running a line of your JavaScript.

Check yours from inside the profile by visiting a handshake reflector and reading the JSON:

https://tls.peet.ws/api/all

Compare the ja4 and akamai_fingerprint fields against the browser your profile claims to be. Then repeat from a command line client through the same proxy, which reports curl's handshake rather than the browser's:

curl -s -x http://USER:PASS@gateway.sparkproxy.io:11002 https://tls.peet.ws/api/all | python -m json.tool | head -40

Those two results should differ. If they come back identical, something in your setup is proxying the browser through an HTTP client that terminates and re-originates TLS, and the browser identity you paid for never reaches the target.

The practical rule follows directly: pick an engine family that matches the browser you intend to present. Present Chrome from a Chromium build. Present Firefox from a Firefox build. Do not present Safari from either.

Engines and patch levels change between releases, so read this as where to point your tests rather than as a result. The result is what your own console prints.

Two notes on that last row. Patchright and undetected-chromedriver solve a different problem: they hide the signs that a driver is attached, not the identity of the machine. They are the right tool for stateless collection and the wrong tool for account isolation. Our comparison of undetected-chromedriver, Patchright and Camoufox covers the tradeoffs, and the head to heads on Multilogin and GoLogin, AdsPower and Multilogin and Dolphin Anty and GoLogin cover the product-level differences.

None of the Chromium builds in that table turns a Chromium handshake into a Safari handshake. Several adjust HTTP/2 settings and header order. Verify rather than assume.

Create two profiles on the same tool, attach a different sticky proxy exit to each, and work through this list. You need a browser, a console, and roughly half an hour.

The coherence snippet is one paste and it catches more real failures than the canvas tests do:

console.log({
  ua: navigator.userAgent,
  platform: navigator.platform,
  uaDataPlatform: navigator.userAgentData && navigator.userAgentData.platform,
  brands: navigator.userAgentData && navigator.userAgentData.brands,
  timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
  language: navigator.language,
  languages: navigator.languages,
  cores: navigator.hardwareConcurrency,
  memory: navigator.deviceMemory,
  screen: [screen.width, screen.height, screen.colorDepth],
  dpr: window.devicePixelRatio,
  touch: navigator.maxTouchPoints,
  webdriver: navigator.webdriver
});

Read every field against every other field. A profile claiming Windows with maxTouchPoints of 0, deviceMemory of 8 and hardwareConcurrency of 12 is fine. The same profile with hardwareConcurrency of 2 next to a 3840 by 2160 screen is describing a machine nobody sells. navigator.userAgentData.platform disagreeing with the UA string is an instant fail, because client hints and the UA string are two encodings of one claim and only a tampered browser lets them diverge.

Record the results in a sheet. Rerun after every tool update, because a Chromium bump changes what the core patches cover and vendors do not always ship both halves at once.

Every failure the protocol above finds takes one of four shapes.

Instability

The same profile produces different values on repeat reads, across restarts, or after an update. Real hardware does not do this. A detector comparing two reads inside one page load gets the signal for free.

Incoherence

Individual values are plausible, the combination is impossible. Apple GPU with a Win32 platform. A macOS font set with a Windows-only face present. Europe/Berlin timezone, en-US as the only accepted language, and a Tokyo exit IP. These are cheap to test at scale because the answer is boolean rather than statistical.

Self-disclosure

The masking is visible to the page. Patched functions that print JavaScript instead of [native code], properties defined with the wrong descriptor flags, prototype chains that acquired an extra link, error stacks naming an injected script. The site does not need to evaluate your fingerprint if it can see the tool that produced it.

The layer gap

The browser layer is flawless and the layers around it are untouched. TLS says Chromium under a Safari UA. WebRTC reports an address the proxy was supposed to hide. The exit IP geolocates two thousand kilometres from the timezone. This is the most common failure in production and the one no antidetect vendor can fix for you, because the network side is not their product.

A fingerprint is never evaluated in isolation. It is evaluated together with the connection that delivered it. Perfect masking above the socket plus a contradictory socket is worse than no masking at all, because default Chrome on Windows in the correct timezone hides inside a crowd of hundreds of millions, while a hand-tuned profile with a mismatched exit is a population of one.

Two of those deserve detail.

WebRTC over a SOCKS5 tunnel

SparkProxy SOCKS5 on port 13000 carries TCP. WebRTC gathers ICE candidates over UDP. Those two facts together mean UDP candidate traffic does not travel through the tunnel, so the browser can learn and report an address the proxy never touched. The antidetect profile must therefore set WebRTC to replace the public address with the proxy exit, or disable it outright, and you have to verify the setting rather than trust it. Check BrowserLeaks WebRTC in the live profile after every tool update. Our guide to WebRTC leaks covers the candidate types, and DNS leak testing covers the resolver side of the same problem.

Choosing the right ASN class for the job

Be honest about the work. Stateless collection, price monitoring, SERP tracking, ad verification, localization QA and catalogue diffing all run fine from datacenter exits, and a datacenter ASN is not a contradiction for a script that never claimed to be a household. Consumer account platforms are a different case, and there the ASN class is part of the identity you present. The distinction is laid out in residential versus datacenter proxies. Pick deliberately, then make everything else agree with the choice.

SparkProxy datacenter proxies expose one host and three ports:

The rule for antidetect work is one sticky exit per profile, never the rotating port. Rotating the IP under a logged-in session looks like account takeover, which is the one behaviour every consumer platform is built to catch. See sticky session proxies for how session lifetime works.

Confirm the exit before you configure the profile around it:

curl -s -x http://USER:PASS@gateway.sparkproxy.io:11002 https://ipinfo.io/json

{
  "ip": "203.0.113.44",
  "city": "Frankfurt am Main",
  "region": "Hesse",
  "country": "DE",
  "timezone": "Europe/Berlin"
}

Derive the profile from that JSON rather than picking values you like. Timezone Europe/Berlin. Language de-DE, with en-US second if the persona would plausibly have it. Screen resolution from a common German consumer configuration, not from the monitor in front of you.

If you drive a plain browser instead of a commercial antidetect tool, the same derivation applies:

const { chromium } = require('playwright');

const browser = await chromium.launch({
  proxy: {
    server: 'http://gateway.sparkproxy.io:11002',
    username: 'USER',
    password: 'PASS'
  }
});

const context = await browser.newContext({
  locale: 'de-DE',
  timezoneId: 'Europe/Berlin',
  viewport: { width: 1536, height: 864 },
  deviceScaleFactor: 1,
  userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36'
});

One caveat from our own docs: Playwright connects to a SOCKSv5 proxy but silently ignores the username and password, so on port 13000 authenticate by IP whitelist rather than credentials, or use the HTTP port instead.

When you do not need any of this

If nothing logs in, the whole fingerprint maintenance problem is optional. A managed request handles the browser stack for you and there is no profile to keep coherent:

import requests

r = requests.get(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": "YOUR_API_KEY"},
    params={
        "url": "https://www.sparkproxy.io/pricing",
        "render_js": "true",
        "country_code": "DE",
        "stealth": "true",
        "format": "md",
    },
    timeout=120,
)
print(r.status_code, r.text[:400])

country_code sets the exit region, stealth adds a homepage pre-warm, a forced referrer and longer idle delays, and format=md returns Markdown instead of raw HTML. The full parameter reference is at /docs/scraping-api. An antidetect browser earns its subscription when you need persistent, separable identities. For everything else it is overhead you pay to maintain.

SparkProxy datacenter proxies include a 24-hour trial, which is enough time to run the entire twelve-test protocol above against a real exit before committing to a plan.