Why everything happens locally
Most online file tools work by uploading your file to a server, processing it, and sending it back. That means your image sits on someone else's disk for at least a little while. It also means the tool stops working the moment the server does.
These tools are built differently. The processing uses browser APIs — Canvas for drawing, JavaScript for encoding, WebAssembly where it helps. Your file is read from your disk into memory, transformed, and handed back as a download. Nothing is transmitted.
You can verify the claim rather than trust it. Open your browser's developer tools, switch to the Network tab, and generate something. You will see no request carrying your file.
What that means in practice
- Privacy is structural, not a promise. There is no upload step to opt out of.
- No account. Nothing to register for, because there is no state to store.
- No watermark. The output is the file you asked for.
- No queue. Encoding happens on your machine, so there is nothing to wait in line for.
Where things can still go wrong
Running locally has trade-offs worth knowing about. Large files depend on your device's memory and speed — a GIF with several hundred frames will be slower on an older laptop than on a new one. Very large jobs can be limited by the browser itself, which is why the tools enforce caps on frame count and canvas size rather than letting a tab lock up.
GIF is also an old format with real constraints: 256 colors per frame, no partial transparency, and file sizes that grow quickly with frame count. Where a limit is hit, the tool tells you rather than silently producing something broken.