excelback.com sets no cookies for anyone just reading, searching, or using a tool. The one exception is the optional "Sign in with Google" link at /account — clicking it, and only clicking it, sets a cookie. Nothing else on the site does, and nothing on the site ever requires clicking it, which is why you were not shown a consent banner.
Why there is no banner
Consent banners exist because a site wants to store or read something on your device that it needs permission for. For everyone who never signs in, this site does neither, so asking would be theatre — there is no cookie to accept, no "manage preferences" panel behind which a hundred vendors are hiding, and no legitimate-interest tab. The sign-in cookie is different in law, not just in effect: it is set only when you deliberately click "Sign in with Google", exists purely to keep you signed in, and is exactly the kind of "strictly necessary" cookie that consent banners were never meant to gate — the request to sign in is the consent.
That is a design decision, and it constrains other decisions. Any analytics this site uses must be cookieless for the same reason. See the privacy policy for what that means in practice.
What the site stores on your device
| Mechanism | Used? |
|---|---|
| Cookies | Only if you use the optional Google sign-in — see below. |
localStorage | Only one flag, only if you subscribe to the email newsletter — see below. |
sessionStorage | Yes, narrowly — see below. Not cookies, not localStorage. |
| IndexedDB | No. |
| Service workers / Cache Storage | Yes, narrowly — see below. |
| Fingerprinting of any kind | No. |
This site also registers a service worker (production only, not on this preview/dev build) that caches exactly one page — /offline/ — so that losing your network connection shows a plain offline notice instead of the browser's default error screen. It does not cache the rest of the site, does not run on every visit before you've been here once, and stores nothing that identifies you; it exists purely so one fallback page is available without a network request.
Your browser will cache the site's own files — pages, styles, images, the search index — the way it caches any website. That is ordinary HTTP caching under your browser's control, not storage we write or read, and you can clear it whenever you like.
sessionStorage, specifically
A handful of on-page prompts — a floating "support this site" bar, and small banners suggesting a tool, template, or article that might be relevant to what you're reading — remember two things for the rest of your visit: that you dismissed them, and (for a couple of the banners) which pages you've already opened, so the same suggestion doesn't repeat itself. That is the entire contents of what gets written.
- It lives in
sessionStorage, which the browser itself erases the moment you close the tab — there is nothing to "clear" by hand, and nothing survives to a later visit. - It is never sent anywhere. It is read back only by the page you are already on, in your own browser, to decide whether to show a banner you've already seen.
- It contains no identifier, no name, no IP address, and nothing that would mean anything outside this browser tab — just a handful of flags like "the donate bar was closed" or "the /tools page was opened".
sessionStorage is why the table above can still mostly say "no" to persistence: that mechanism erases itself when you close the browser, which is the distinction this policy exists to draw. The one thing that genuinely persists is the newsletter flag described next — and only for people who asked for it, by subscribing.
Newsletter signup, specifically
The popup offering email updates writes exactly one thing tolocalStorage, and only after you successfully subscribe: a flag so the popup doesn't ask again on a later visit. It contains no email address and no identifier — it's the same kind of "already asked, don't ask again" marker the donate bar uses, just persistent instead of per-session, because a subscription itself is meant to persist.
The email address itself goes to our server and is stored in a database table used only for sending you updates — see theprivacy policy for what that table holds. Every email includes a one-click unsubscribe link.
Sign-in cookies, specifically
Clicking "Sign in with Google" at /account sets two cookies, both httpOnly (invisible to any script running on the page, ours or anyone else's):
- A short-lived one that exists only for the few seconds between leaving for Google and coming back, so we can tell your redirect apart from a stranger's. It is deleted the moment you land back on the site, whether sign-in succeeded or not.
- A session cookie, set only after Google confirms who you are, that keeps you signed in on later visits for up to 30 days. It contains a random token, not your name or email — the token is looked up against our database to identify your account.
Signing out (from /account) deletes the session cookie and its matching database record immediately. Neither cookie is set, read, or checked on any page unless you have clicked "Sign in with Google" at some point.
Third-party embeds
One, and only on pages with videos. Everything else on a page — including the fonts, which used to come from Google — is served from this domain.
YouTube video player
Video cards use YouTube's youtube-nocookie.com domain, and the player is not loaded at all until you click play — the frame's src is empty before that and is cleared again when you close the video. If you do play something, YouTube's own storage and terms apply from that moment, and that is genuinely their cookie rather than ours.
The still image on a video card comes from i.ytimg.com, so pages showing video cards make one image request to Google per thumbnail.
Blocking any of it
Both YouTube requests can be blocked with any content blocker or by your browser's own settings, and nothing on this site depends on them. Thumbnails go blank and video playback stops working; every page, tool, search and font still works, because those are all served from this domain. None of the tools need the network once the page has loaded.
If this changes
Adding anything that stores data on your device would mean rewriting this page and, where the law requires it, asking you first. The date at the top tells you when it was last true.
Questions about this page, or anything else on this site: support@excelback.com. It is the only contact route the site has — there is no form here that submits to a server.
