About

There is no cookie banner because there are no cookies

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

Most sites that say this say it in a privacy policy, which is a promise. The point of this page is that here it is a consequence of how the thing is built, and you can check every claim on it yourself in about two minutes. Instructions for doing exactly that are at the bottom.

This website

No cookies. Not one. Nothing here sets a cookie, first-party or third-party, essential or otherwise. There is no session to keep, because there is 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 is strictly necessary — so with nothing stored, there is nothing to ask you about.
No analytics, 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. 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 does not flash the wrong colour scheme on your next visit. It is not a cookie, it is never sent anywhere, it is 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 would least like to hand to a stranger: frequency plans, rig drawings, venue geometry, client decks, the PDF you are presenting from in an hour.

They never leave your browser. Not "we delete them afterwards", not "we do not look at them" — they are not transmitted at all. Every one of the 15 tools is a Cloudflare Worker configured to serve static files and nothing else: its entire deployment config names a directory of assets and declares no server code. There is no endpoint. There is no upload handler. There is no runtime on the server capable of executing a line of anything, so there is no destination for a file to go to even by accident.

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 — 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 do not re-enter them each time. No file contents, no identifiers, and nothing that leaves the machine.
Close the tab and it is gone. There is 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 is the application arriving, from this domain, in response to what you opened. It is not your file departing.

The exceptions, stated plainly

A page like this is only worth reading if it also lists the places data does move. There are five. None of them is a cookie, the first three 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. Both are optional — the email address is on the contact page if you would rather use your own mail client.
One tool downloads 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 is an outbound download of a public file, requested by you, and your presentation is not part of the request — the deck stays where it always was.
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 is unavoidable for anything served over the internet, it is not something added here, and none of it is joined up, stored by us or used to build a profile.
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 is worth naming because it is the one request on the whole site that is not simply fetching a file, so anyone following the instructions below will spot it. It is not ours, it sets no cookie, it carries nothing you have 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 requires taking anyone's word for it, and the honest version of a privacy page is one that tells you how to falsify it.

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. Every request you see will be a GET for a file on that same domain — the tool fetching more of itself. Nothing is sent upward, and no request has your file as its body.
Check the sizes. An upload is not subtle. A rig file is megabytes; if it were being transmitted there would be a request the size of the file, and there is not 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; there is no server code in the repository to review, which is rather the point.

Why it is built this way

Partly principle: a tool you use at work should not 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 is not really yours to do.

Mostly, though, it is 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.