Your workbook stays on your device

There is no upload. No server sees your file, because no server is involved in processing it. Here is what that rests on, so you can check rather than take our word for it.

The site is static files

Every page is a file served from a CDN. There is no account and no endpoint that accepts a workbook. The server side is a few dozen lines: it sends www and our second domain to this one, it counts finished runs, and it takes feedback you choose to send. It never reads a request body from this page, because no route the page calls accepts one. The work happens in WebAssembly running in a worker inside your browser tab.

Static hosting alone would not be enough

A static site can still ship a script that sends data somewhere. So two further measures apply. The site sends a Content-Security-Policy that names every place it is allowed to reach, and on top of that the page and the worker install a guard, before any file is read, that refuses requests anywhere else and refuses any request to this site carrying a body.

One analytics script, and what it can see

Cloudflare Web Analytics counts page views. It sees the address of the page, the referring link, and coarse device information, the same things any web server logs. It sets no cookie and follows nobody between sites.

It is not given your workbook. The page reads your file, hands it to a worker that does the work, and receives the result and the report back; the analytics script is never passed any of that, and the worker's own guard allows no host at all. A worker is not a wall, though: any script running in the page could in principle read the file input, so the real guarantee is what is loaded, and that is one analytics beacon and nothing else. No tag manager, error reporter, font CDN or embedded widget.

What a run counts

A run says two things. Before it starts: the size of the file, how much data the package says it holds unpacked, and the extension it came on. When it finishes: the size after, how long it took, which reductions ran, and how the space inside was divided between worksheets, images, pivot caches and the rest. That is the whole list. There is no file name, no sheet name, no part name, no account and no cookie, and nothing is stored that could pick your file or you out of the pile.

The line sent first is there for the runs that do not come back. A workbook big enough to exhaust a browser tab can take the page down with it, and until it said something beforehand, those were the only runs we never heard about, which is how the size limit stayed a guess. Two sizes and an intention, sent before any of your data is read.

It goes as a plain link with the numbers in it, not as an upload, which is why you can read the entire thing in the Network tab before deciding whether you mind. The rule that no request from this site may carry a body stays exactly as it was, and that is the rule a workbook would have to break to leave your machine.

If you send feedback

The Feedback link in the footer opens a form. What you type goes to us at feedback@shrinkexcel.com, along with your email if you give one, and is kept so we can answer it. If you open the form from a result or an error, it adds a short line of context: the engine version, the sizes before and after, and the reductions that ran, or the error message the page showed you. The form shows you that line before you send. It never includes the workbook or its file name. An error message can name a part inside the workbook, such as a sheet's file, so read the line if that matters to you. Like a run's numbers, it goes as a link rather than an upload, so the no-body rule above still holds.

The two things kept on your device

Picking light or dark from the switch in the header writes the word "light" or "dark" to this site's local storage, so the next page keeps it. Sending feedback with your email writes that address there too, so the form is filled in next time. Send one with the email box cleared and the address is removed. Those are the only two keys the site writes. Nobody else can read them. The stored address only fills in the box, and it leaves only when you press Send with it there. Clearing site data removes both. Leave the switch and the form alone and nothing is written at all: the page follows whatever your system is set to.

What you can check yourself

Open your browser's developer tools, switch to the Network tab, and shrink a file. You will see the page's own assets, one request to the analytics beacon when the page loads, two links to /api/run with their numbers spelled out in the address, one as the run starts and one as it ends, and nothing at all in between while your file is being read. Working offline is a stronger check: load the page, disconnect, and shrinking still works.

The limits are ours, not your browser's

The page refuses workbooks past a size, and that size is a number we chose, not one any browser publishes. Nothing reports how much memory a tab will give you, so past our own budget the page asks yours directly: it tries to reserve the memory the job needs, and runs the file if the browser hands it over. That reservation is released straight away and reads nothing. It is the only thing on this page that treats your machine as a source of an answer rather than a place to stay out of, and what it learns is one yes or no.

The report is yours

The verification report lists the parts inside your workbook by name, so it is generated locally and downloaded locally. It is never transmitted. The counts described above are totals taken from it; the names it contains stay on your machine.