Skip to main content
ShieldLabs runs as a single JavaScript snippet, so it works wherever a modern browser does. The same code path runs on Chrome, Firefox, and Safari alike, and the same browser keeps its DeviceID across repeat visits. The product is web only: a single snippet loaded from the CDN, with no native SDK or npm package today. Mobile and platform support is covered in Mobile and platforms below.

​
Supported browsers

The snippet recognizes every mainstream desktop and mobile browser, and identification runs the same way in all of them: a visitor returning in the same browser keeps the same DeviceID. A different browser produces a different DeviceID for the same person, so identity-based counts are best read within the identifier boundaries. Other mainstream browsers, such as Vivaldi and Yandex Browser, are recognized and identify the same way. A browser that reports an unfamiliar user agent still gets a DeviceID; it is simply labeled as unknown rather than by name.
ShieldLabs does not publish minimum browser versions. Identification works on current releases of every browser above. Support is detected by capability, not by a spoofable user-agent string, so an anti-detect browser cannot fake its way into a different support tier.
Some anonymity signals are available on Chrome, Edge, Opera, Brave, and Samsung Internet that Firefox and Safari do not expose. The same masked visitor can therefore score slightly lower on Firefox or Safari. That is expected coverage, not a setup error: the identity is unaffected, only the anonymity signals available to the score differ.

​
How persistence behaves per browser

Browsers differ most in how long they keep first-party cookies and site storage. That matters because two identifiers depend on storage and one does not.
  • DeviceID is derived on the server from hundreds of stable browser and device characteristics. Nothing about it is stored in the browser, so no privacy setting can expire it.
  • VisitorID is built from the DeviceID combined with the cookie-based CookieID. When a browser clears or shortens cookie storage, the CookieID resets and a new VisitorID is minted.
So privacy defaults reset the VisitorID but leave the durable DeviceID intact, as the full identifier model lays out.

​
Safari

Safari is privacy hardened by default. Apple caps the lifetime of script-writable storage and first-party cookies set by JavaScript, so the CookieID expires sooner than on other browsers.
  • Affects the VisitorID. A returning Safari visitor whose cookie storage has expired gets a fresh CookieID, and therefore a fresh VisitorID.
  • Does not affect the DeviceID. VisitorID resets, DeviceID unaffected, so returning visitors are not miscounted as new.
This applies to desktop and mobile Safari, and to other browsers on iOS, which behave the same way.

​
Brave

Brave is a privacy-hardened browser that behaves like Chrome running an aggressive ad and tracker blocker.
  • Brave may block the snippet host or randomize some browser attributes.
  • Identification still works once the snippet host is allowed, one of the steps for keeping accuracy high below.
  • Some anonymity signals may contribute fewer entries when attributes are randomized. The DeviceID remains stable.

​
Incognito and private mode

Private and incognito windows are fully supported. A private window is the same browser on the same machine, so the DeviceID is stable across normal and private sessions on that browser.
Recognition holds through incognito and private mode: a returning visitor keeps the same DeviceID whether or not they use a private window.

​
Keeping identification accuracy high

A few setup choices keep accuracy as high as possible, especially on privacy-hardened browsers.
  • Allow the snippet host. Make sure cdn.shieldlabs.ai and the data endpoints are not blocked by an ad blocker or a Content Security Policy. A blocked snippet collects nothing, so the DeviceID comes back all-zero, which Troubleshooting covers in full. Treat an all-zero DeviceID as “nothing collected,” not as a returning visitor.
  • Keep first-party storage available. Clearing or stripping cookies does not change the DeviceID, but it does reset the VisitorID and visit counts. Leave first-party storage in place where you can.
  • Pass a hashed UserHID for signed-in users. Once a visitor logs in, call the checkAuthenticatedUser export with a hashed account id. This ties anonymous activity to a known account across visits and browsers.
  • Use the framework integration. The React, Vue, Angular, Preact, Svelte, and native-JS wrappers all load the same module from the CDN. They keep the import in your app code where it is easy to maintain.
Identity-based counts are best read as estimated, not exact, within the identity boundaries.

​
Mobile and platforms

Mobile web is a first-class target. The snippet runs in mobile Chrome, mobile Safari, Samsung Internet, and other mobile browsers exactly as it does on desktop. There is no native mobile SDK today. ShieldLabs identifies users inside the mobile browser, not inside a native app. A WebView that runs standard browser JavaScript can load the snippet, but a fully native app screen has no browser context to collect from.

​
Next steps

Identification

The six identifiers, and why the DeviceID outlives cleared cookies.

Accuracy

How corroborating multiple signals gets identification up to 99%.

Content Security Policy

The exact directives that keep ad blockers and CSP from blocking the snippet.