Skip to main content
ShieldLabs runs as one JavaScript snippet loaded from cdn.shieldlabs.ai, so it works wherever a modern browser does: desktop and mobile browsers, and app WebViews that load your web pages. The same browser keeps its Device ID when the user returns, and a signed-in user keeps one User HID on every browser and device they use. Mobile and platforms below covers each surface.

​
Supported browsers

The snippet recognizes every mainstream desktop and mobile browser, and identification runs the same way in all of them: a user returning in the same browser keeps the same Device ID (Brave randomizes some attributes). Another browser is another Device ID, so pass a hashed User HID on signed-in pages: the user then links every device and browser the account signs in from, and counts per device 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 Device ID; it is simply labeled as unknown rather than by name.
Identification works on current releases of every browser above. Support is detected by capability rather than by the user-agent string, so an anti-detect browser cannot fake its way into a different support tier.
Some risk signals are available on Chrome, Edge, Opera, Brave, and Samsung Internet that Firefox and Safari do not expose. The same masked user can therefore score slightly lower on Firefox or Safari. That is expected coverage rather than a setup error: the identity is unaffected, only the risk signals available to the Risk Score differ.

​
How persistence behaves per browser

Browsers differ most in how long they keep first-party cookies and site storage. That matters for the Cookie ID and the Visitor ID only.
  • Device ID is computed on the server and kept out of browser storage, so settings that clear cookies or storage leave it in place.
  • User HID is the account id you pass, so browser storage never changes it.
  • Visitor ID is one device plus one cookie. When a browser clears or shortens cookie storage, the Cookie ID resets and a new Visitor ID is created.
So privacy defaults reset the Visitor ID and leave the Device ID and the user 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 Cookie ID expires sooner than on other browsers.
  • Affects the Visitor ID. A returning Safari user whose cookie storage has expired gets a new Cookie ID, and therefore a new Visitor ID.
  • Leaves the Device ID in place. The Visitor ID resets and the Device ID holds, so a returning device is not counted 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 risk signals may contribute fewer entries when attributes are randomized.
  • Pass a hashed User HID on signed-in pages, so a Brave user stays linked to the account whatever the browser randomizes.

​
Incognito and private mode

Private and incognito windows are fully supported. A private window is the same browser on the same machine, so the Device ID is stable across normal and private sessions on that browser.
Recognition holds through incognito and private mode: a returning user keeps the same Device ID 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.
  • Pass a hashed User HID on every signed-in page. Call the checkAuthenticatedUser export with a hashed account id. Users, account-level risk and all four High-Risk Events are built on it, and the user links every device, browser and visitor the account signs in from.
  • Allow the snippet host. Make sure an ad blocker or a Content Security Policy leaves cdn.shieldlabs.ai and the data endpoints open. A blocked snippet sends nothing, so no identification reaches your webhook. An all-zero Device ID (00000000-0000-0000-0000-000000000000) means no usable device signals reached ShieldLabs for that identification; the rate-limit marker (Risk Score 999) is one such case. Route it to review rather than allowing it. Troubleshooting covers both cases.
  • Keep first-party storage available. Clearing or stripping cookies leaves the Device ID in place, but it resets the Visitor ID and unique visitor counts. Leave first-party storage in place where you can.
  • Use the framework examples. The framework integrations for plain JavaScript, React, Next.js, Angular, Vue, Preact and Svelte load the same module from the CDN and keep the import in your app code, where it is easy to maintain. WordPress, Tilda and Shopify have their own tabs on the same page.
Device and visitor counts are estimates: read them within the identifier 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, and inside app WebViews that load your web pages.

​
Next steps

Identifiers

Users, devices and visitors, and why the Device ID holds through cleared cookies.

Accuracy

99.9% identification accuracy and 99.9% risk signal detection accuracy, and how they are measured.

Content Security Policy

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