Why We Built a Privacy-First Sprite Tool (And What That Means for You)

Many sprite and atlas tools run in the cloud: you upload your assets, they process them, you download the result. That's convenient but means your game art—often unreleased or under NDA—passes through someone else's servers. We built a tool that runs entirely in the browser so your files never leave your machine. This post explains what "runs in the browser" means in practice, why it matters for game dev and compliance, and what the tradeoffs are so you can decide if local-first is right for your team.

What "Runs in the Browser" Means

All processing happens in your browser tab using WebAssembly (e.g. FFmpeg for video decode) and the Canvas API for drawing and compositing. When you drop a video or image set, the file is read locally; no bytes are sent to our servers. Generated sprite sheets and atlases are created in memory and offered as downloads; again, nothing is uploaded. So your source art and your output stay on your device.

In our implementation, no account is required to process your files: you don't hand over an email or API key that could be tied to your assets. Analytics or telemetry, if any, can be limited to usage stats (e.g. which features are used) without ever seeing your images or video. For teams in regulated industries or with strict IP policies, "nothing leaves the machine" is easy to explain and audit.

Technical flow

Your file is opened via the File API or drag-and-drop; the bytes stay in the browser's memory. WebAssembly decodes video or reads images; Canvas (or similar) composites the result. The output is a Blob or array buffer that you trigger as a download. No form upload, no fetch to our backend for the asset itself. The only network requests are for loading the app and optional analytics; your art is never part of those requests.

Why That's Better for Game Dev

Game assets are often confidential. Avoiding upload removes the risk of leaks, logging, or retention on third-party infrastructure. It also means we don't need to store or process your data, so our privacy story is simple: we don't have your assets. For studios and indies who care about IP and compliance, local-first is a clear win.

Unreleased characters, levels, and effects are valuable. Sending them to a third-party server creates a chain of custody and potential exposure. Even with policies and encryption, a breach or a misconfigured log could leak assets. Local processing eliminates that vector. It also simplifies compliance with data-residency or "no cloud" requirements that some studios or publishers have. You get the same sprite sheet and atlas output without the trust and compliance burden of cloud processing.

Limitations

Heavy work runs on your CPU and memory. Very large videos or huge image sets may slow down or hit browser memory limits. We optimize where we can (e.g. downscaling for preview) and recommend modern browsers and enough RAM for big jobs. The tradeoff—no upload, no server—is worth it for many teams.

For the largest jobs (e.g. 4K video, thousands of high-res images), consider splitting the work or using a powerful machine. Browsers have tab memory limits and may throttle long-running scripts; progress indicators and chunked processing help. We don't have access to your machine, so we can't run jobs in the cloud on your behalf—the tradeoff is intentional: your data stays local, and you own the compute. For most sprite sheet and atlas workflows (hundreds of frames, typical resolutions), modern hardware and a recent browser are sufficient.

Summary

Local-first means no upload, no server storage, and no need to trust a third party with your art. Processing runs in the browser via WebAssembly and Canvas; you download results directly. That benefits game dev and anyone with confidential or compliance-sensitive assets. The tradeoff is that heavy jobs run on your device; we optimize and recommend capable hardware for large inputs.