About

There's no cookie banner because there are no cookies

No consent form, no tracking scripts, no accounts, no cookies. Load a show file into one of the browser tools and it's processed on your own machine. It's never uploaded, because there's nothing at the other end that could receive it.

Most sites that say this say it in a privacy policy, which is a promise. Here it's a consequence of how the thing is built, and you can check every claim on this page yourself in about two minutes. The instructions are at the bottom.

This website

No cookies. Not one. Nothing here sets a cookie, first-party or third-party, essential or otherwise. There's no session to keep, because there's nothing to log in to. Under the ePrivacy rules a banner is required when a site stores or reads information on your device beyond what's strictly necessary, so with nothing stored, there's nothing to ask you about.
No analytics scripts, and no tracking pixels. No Google Analytics, no Plausible, no Meta pixel, no beacons. The by the numbers page counts release downloads and stars reported by GitHub's public API (repositories, not visitors) and shows how often each browser tool is opened. That last figure is Cloudflare's own count of the requests it serves at the edge for each tool's address, published as one total per tool from a sample. Nothing runs in your browser to produce it, and it says how many, never who. Nobody here knows you read this page.
No web fonts, no CDN scripts. The site is set in whatever sans-serif and monospace your operating system already has, so your browser never fetches a font from anyone. Every stylesheet and script is served from this domain.
Videos load nothing until you press play. Project videos are a still image and a play button, not an embed. Click one and it swaps in a youtube-nocookie.com player, so a page full of project cards costs Google nothing and tells them nothing unless you actually decide to watch.
One thing is stored, and only if you ask for it. Clicking the light/dark toggle writes sw-theme to your browser's local storage, so the site doesn't flash the wrong colour scheme on your next visit. It isn't a cookie, it's never sent anywhere, it's readable only by this domain, and clearing site data removes it.

The browser tools

This is the part worth being specific about, because these tools open the files you'd least like to hand to a stranger: frequency plans, rig drawings, venue geometry, client decks, the PDF you're presenting from in an hour.

They never leave your browser. This isn't a promise to delete them afterwards, or not to look at them. They're never transmitted at all. 32 of the 33 tools are a Cloudflare Worker configured to serve static files and nothing else: the entire deployment config names a directory of assets and declares no server code. There's no endpoint and no upload handler, and no runtime on the server capable of executing a line of anything, so there's no destination for a file to go to even by accident.

The one exception is the BirdDog PLAY Patcher, and it's worth mentioning here rather than only in the list below. It does have a small script, because two of the things it can put inside the firmware package, Tailscale's own release and the MediaMTX the streaming gateway runs on, come from download servers that won't let a browser fetch them directly. That script relays those public files. It answers four addresses, allGET, and the only thing you can hand it is a version number. Your key, your options and the package it builds are never part of the request.

The parsing happens on your machine. The same code that runs in the desktop builds is compiled to run in a tab. Opening a file uses your browser's file picker, which hands the tool the bytes directly, so the file is read from your disk into your own memory and never travels.
Exports are generated locally too. When a tool gives you back a coordination file, an XML config or a rendered image, your browser built it. Nothing was round-tripped through a server to produce it.
Nothing is remembered between visits except your settings. Some of the tools keep your own preferences in your browser's local storage (units, default sizes, the last layout you used) so you don't re-enter them each time. No file contents, no identifiers, and nothing that leaves the machine.
Close the tab and it's gone. There's no history, no recent files list on a server, no account holding your work. The tools are stateless in the way a calculator is.
The only requests are for the tool's own code. Several tools fetch part of themselves on demand: open a drawing in ArrayCAD and the CAD reader is downloaded at that moment, because shipping every importer to everybody on first load would make the tool enormous. That's the application arriving, from this domain, in response to what you opened. It isn't your file leaving.

Where data does move

A page like this is only worth reading if it also lists the places data does move. There are seven. None of them is a cookie, the first five happen only because you asked for them, and the last two are the plumbing every website sits on.

The forms send what you type into them. The contact form and the problem report form do exactly what a form does: your name, your email address and your message are transmitted so that somebody can reply. Contact goes via Web3Forms, which relays it to an inbox; feedback goes to an intake endpoint on this domain, as does a report sent from the footer of a browser tool. All of them are optional, and the email address is on the contact page if you'd rather use your own mail client.
Two tools download fonts from public CDNs. When you ask the PowerPoint Font Manager to fetch a font it has identified, your browser downloads that font file from the Google Fonts repository on GitHub or the Fontsource CDN. That's an outbound download of a public file, requested by you, and your presentation isn't part of the request. The deck stays where it always was. OpenFont Manager downloads from the same two places, and its catalogue shows each Google family in its own face, fetched from Google Fonts as the card scrolls into view.
Two tools look things up where you point them. Paste a published Google Sheet's link into the Thumbnail Generator and your browser fetches that sheet from Google. openflash asks download.lineageos.org which builds exist for the phone you picked. Neither request carries anything of yours beyond the link or the model.
One tool relays downloads from Tailscale and GitHub. The BirdDog PLAY Patcher builds a firmware package in your browser, and Tailscale's arm64 release is one of the things that can go inside it, as is the MediaMTX the streaming gateway runs on. Neither download host lets a browser fetch them, so those files are relayed by a script on the tool's own address, which is the only server code on any of these tools. It's given a version number and nothing else, and the browser checks what comes back against each project's own published SHA-256 rather than trusting the relay. Hand the tool a Tailscale tarball from your own disk instead and that request never happens at all.
simpleRTA listens to your microphone, locally. The analyser needs audio, so your browser asks permission for the microphone. The audio is analysed in the tab and is never recorded, stored or transmitted; revoke the permission or close the tab and it stops.
The host sees the request itself. Cloudflare serves these pages, and like every web server in existence it handles the connection (your IP address, the URL you asked for, your browser's user agent) as part of delivering the response. That's unavoidable for anything served over the internet, it isn't something added here, and none of it is joined up, stored by me or used to build a profile. The one thing read back out of it is a total per tool subdomain (how many requests and visits Cloudflare counted for each browser tool), which is what the by the numbers page shows. A count, never a list of who made it.
Cloudflare runs its own bot check. On this site the edge injects a small script of its own that looks at your browser and reports back to Cloudflare, on a /cdn-cgi/ address on this same domain, to tell visitors apart from scrapers. It's worth naming because it's the one request on the whole site that isn't just fetching a file, so anyone following the instructions below will spot it. It isn't mine, it sets no cookie, it carries nothing you've opened, and on several of the tool subdomains this site's own content-security policy blocks it outright.

Check it yourself

None of the above needs you to take anyone's word for it, so here's how to try and prove it wrong.

Look for the cookies. Open your browser's developer tools, Application or Storage, then Cookies. This domain will be empty. So will every tool subdomain.
Watch the network while you work. Open a tool, open the Network tab, then load your file. Apart from the downloads listed above, every request you see will be a GET for a file on that same domain, which is the tool fetching more of itself. Nothing is sent upward, and no request has your file as its body.
Check the sizes. An upload isn't subtle. A rig file is megabytes; if it were being transmitted there would be a request the size of the file, and there isn't one.
Read the source. The tools are public and MIT-licensed. The deployment config for each is a four-line file naming a folder of static assets, and there's no server code in the repository to review, which is rather the point.

Why it's built this way

Partly principle: a tool you use at work shouldn't be a data collection exercise, and the industry these are written for handles files that belong to clients, venues and productions rather than to the person opening them. A frequency plan is somebody else's confidential document. It has no business being on a stranger's server, and consenting on its behalf isn't really yours to do.

Mostly, though, it's because the alternative is worse in every direction. A backend would mean a server to secure, a breach to be responsible for, a bill that scales with use, a thing to keep running for years, and a page like this full of careful words about retention periods. Serving static files means none of that exists, the tools are faster, they work in a venue with no usable WiFi, and the privacy question answers itself.