Cookie Policy

This page explains the cookies and browser storage RunTheTests uses. The short version: very little, and nothing that tracks what you do inside a tool.

1. What cookies are

Cookies are small files a site stores in your browser. Related technologies — localStorage and sessionStorage — do a similar job. We use the minimum needed for the site to work and to remember your preferences.

2. What we store ourselves

• Theme preference — a single value in localStorage remembering whether you chose light, dark or system. It never leaves your browser.
• Tool settings — some tools remember your last choices (units, options) in local storage so you do not re-enter them. This too stays on your device.
• Your consent choice — when you answer the cookie banner, our consent manager (InMobi Choice) records the answer in your browser so you are not asked again on every page. This one is necessary rather than optional: without it there is nowhere to store the fact that you said no.

None of this is a tracking cookie, and none of it is sent to us. You can clear it any time through your browser settings.

3. What we do not store

We do not set analytics or tracking cookies on what you type, paste or upload into a tool. The inputs to a tool are not logged and are not tied to any identifier. Tools that make a network request to work do so to perform the lookup, not to track you.

4. Analytics and session replay

Two tools, both answering the same question — which pages get used, and where a tool loses people. Both are governed by the banner, and neither stores anything on your device unless you consent.

• Google Analytics — page views and traffic sources. Sets _ga and _ga_…, but only once you have consented. Before that it runs in Google’s consent mode: it reports that a page was viewed without writing to your device and without linking the visit to any earlier one.
• Microsoft Clarity — heatmaps and session replay, which reconstruct how a page was scrolled and clicked. Sets _clck and _clsk. This one is not loaded at all until you consent, so before you answer, no request reaches it and there is nothing to delete afterwards.

The two are gated differently on purpose, and it is worth being straight about which is which. Session replay reconstructs the page you were looking at, so it waits for a yes. Counting page views does not, so that tag loads and stays in a storage-free mode until you answer — which means Google is told a page was opened even if you then decline. Neither runs on the pages described in section 6, whatever you choose.

5. Advertising cookies

Some pages carry advertising, and advertising networks may set their own cookies to measure and target ads according to their own policies, which we do not control. These appear only on pages that show ads. Pages that handle passwords, keys or encryption carry no advertising and no third-party scripts at all, so no advertising cookie is ever set on them.

6. Why the ad-free pages are ad-free

The tools that handle passwords, passphrases, hashes and encoding keys carry no advertising, no analytics and no third-party script of any kind, and they ship a Content-Security-Policy that blocks outbound connections outright. This is not a preference about clutter. An advertising tag is arbitrary JavaScript, delivered through a chain of intermediaries, running in the same document with the same access to the page as the tool itself — so a generated password on an ad-bearing page is one compromised tag away from leaving the browser. Keeping those pages free of third-party code is what makes the claim that nothing leaves your device something you can verify rather than something you have to trust.

You can check it yourself in a few seconds: open the page source and read the Content-Security-Policy meta tag, then open your browser’s network panel and use the tool. No request is made. The same policy is asserted at build time, so a page that lost its policy, or an ad-bearing page that gained one, fails the build rather than shipping.

7. Storage is not the same as a cookie

The distinction matters for what you can do about it. Cookies are sent to a server with every matching request; localStorage is never transmitted anywhere by the browser and can only be read by script running on this site. Everything we store for your own benefit — your theme, a tool’s last used options, any result you explicitly chose to save — is localStorage, which is why none of it reaches us even in principle. The exception is your consent choice from section 2: the TCF standard our consent manager implements keeps that in a cookie, because the whole point of it is that other scripts can read your answer before they act on it.

The practical consequence is that saved results live on the device that produced them. There is no account, so there is nothing to sign in to and nothing for us to restore: clearing site data for this domain deletes them permanently. If a result matters, export or print it rather than relying on browser storage, which any privacy tool or cleanup routine may remove without asking.

8. Managing cookies

The analytics and advertising cookies above are governed by the banner you saw on your first visit. Cookie preferences at the foot of every page reopens it, and changing your mind costs the same one click as the original answer did — a withdrawal takes effect on the next page load, and there is no penalty in the site for saying no. Nothing on this site is gated behind consent.

Beyond that you control cookies through your browser: you can block them, delete them, or browse privately. Blocking our small preference storage only means the site forgets your theme and tool settings — every tool still works. Blocking third-party cookies limits ad personalisation without affecting the tools. If a privacy extension blocks the consent manager itself, the banner never appears and nothing optional loads, which is the safe end of the failure.

Contact

Questions about cookies: contact@brightscalelabs.com. See also our Privacy Policy.