Cookies

The tracking script fires one beacon on page load and stops. No cookie is written, no local storage is touched, and no value is read from the browser before or after the visit is counted.

What the script does with browser storage

asset.js does not call document.cookie. It does not call localStorage.setItem or sessionStorage.setItem. It does not open IndexedDB. It does not write to the Cache API. Before the beacon fires, it reads nothing from storage. After the beacon fires, it writes nothing to storage. When the page closes, no trace of the script's run persists in the browser.

The absence is structural. The script was written without any storage call because none is needed to count a page load. Referrer host, screen-size class, and load band are all read directly from the DOM and the performance API in the moment the beacon fires. No prior state is consulted and no state is left behind.

Why that matters under cookie law

Cookie consent banners exist because scripts write identifiers that persist in the browser and can be re-read on later visits. That re-reading is what creates a linkage across sessions. Without a cookie, there is no persistent identifier for the script to set or consult, and therefore no consent trigger for that specific mechanism.

Your site's cookie and consent obligations depend on your jurisdiction, your audience, and what other scripts and services you run. StatelessID's script removes one common trigger — a tracking cookie or localStorage key — but does not determine your full compliance picture. Check with your own legal adviser about what your site requires.

Dashboard session cookies are separate

StatelessID's own dashboard uses a short-lived session cookie so you can stay logged in. That cookie is scoped to statelessid.com. It is never written to your domain and has no relationship to asset.js. When a visitor loads your page, the statelessid.com session cookie is not present in their browser unless they happen to also be logged in to their own StatelessID account.

The two cookies are entirely separate concerns. A visitor to your site never receives a cookie from asset.js, and they never receive the statelessid.com session cookie from the act of visiting your site.

How to verify

Open DevTools in your browser and navigate to the Application panel. Expand Cookies, Local Storage, and Session Storage for your domain. Load your page with asset.js present. Reload it. The lists should be unchanged before and after.

In the Network panel, find the beacon request to statelessid.com. Inspect the request headers. The Cookie header should be absent or empty for that outgoing request. The response will not contain a Set-Cookie header for your domain.

Troubleshooting

If a cookie-scanning tool reports a cookie associated with statelessid.com on your own domain, examine the exact domain field in the report. Session cookies issued by statelessid.com are scoped to statelessid.com and cannot be set on your domain. The report may be flagging a cookie placed by a different script on the page, or inferring from the URL pattern rather than observing an actual write.

If a compliance audit tool lists asset.js as accessing browser storage, export the raw evidence and check whether it observed a live write or applied a heuristic based on the script URL. Load asset.js in isolation — paste the canonical URL into a blank page — and run the Application panel audit yourself. No storage write occurs. If a tool still reports one, contact that tool's support with the reproduction steps.