How Browser-Only Image Animation Protects Your Pictures

Many online image tools begin by uploading a file to a remote server. That model is useful for heavy rendering, but it also means the service receives the image, stores it at least temporarily and must protect it during processing. Purupuru Maker uses a different model: the editor and exporter run inside the browser.

This article explains what that claim means in practice, what remains visible to the website operator, and how you can evaluate similar privacy claims in other creative tools.

Opening a file is not the same as uploading it

When you select an image, the browser grants the page temporary access to that specific file. JavaScript can decode it into pixels for the canvas, but the file does not automatically travel across the network.

In Purupuru Maker, the image is decoded locally, resized when necessary, and placed into a WebGL texture. The painted mask is another local texture. The animation shader combines the source pixels, mask, time and motion settings to draw each preview frame.

There is no image-upload request in this path. The server delivers the application code, but the application processes the picture on the device.

WebGL handles the preview

WebGL gives a web page access to the device's graphics pipeline through a restricted browser API. It is well suited to a wobble effect because the same small mathematical deformation must be applied to many pixels for every frame.

The mask controls the strength at each pixel. The selected preset controls how the displacement changes with time. Direction and speed adjust that motion. The browser redraws the canvas repeatedly, creating a real-time preview without waiting for a render queue.

This local design also explains why performance varies by device. A modern desktop GPU can preview a large image comfortably, while an older phone may benefit from a smaller source. That difference is local computing capacity, not server congestion.

Export also happens locally

For GIF export, the browser renders a known number of frames and passes their pixel data to an in-browser encoder. For video, supported browsers use their media capabilities to encode the canvas animation. The finished Blob is then offered to the browser as a download.

A Blob URL may look like a temporary web address, but it references data held by the current browser process. It is not a public Internet URL and disappears when it is revoked or the page closes.

What the operator can still receive

Local image processing does not mean the entire website has zero data flows. Like other public sites, the hosting provider receives the technical request needed to deliver HTML, JavaScript, fonts and sample images. If a visitor creates an account, pays for a feature or contacts support, the information submitted for that feature must reach the relevant server or provider.

Optional analytics and support widgets are a separate category from image processing. On Purupuru Maker they remain disabled until the visitor makes a choice in the privacy panel. The image itself is not added to analytics events.

The distinction is important: a site can process an image locally while still using ordinary infrastructure for accounts and page measurement. A precise privacy statement should describe each flow rather than making the vague claim that “no data is ever collected.”

How to verify a browser-only tool

You do not have to rely only on marketing copy. A technically curious visitor can check:

1. Open browser developer tools and select the Network panel.
2. Clear the request list.
3. Choose a test image that contains no sensitive information.
4. Paint, preview and export it.
5. Look for an upload request with a large request body or image MIME type.

Normal requests for scripts, fonts, analytics after consent, or sample images do not contain the selected local file. An upload endpoint receiving the file would be a different architecture.

You can also test the editor after the initial page has loaded by temporarily going offline. Local preview and export should continue as long as the required application code is already available.

When local processing is the right tradeoff

Browser-only processing is especially useful for personal photos, unreleased art, client drafts and quick experiments. It reduces exposure, removes upload wait time and avoids a server-side render queue.

It is not automatically the right design for every creative task. Large machine-learning models, collaborative projects and cross-device storage may need server infrastructure. The honest question is not whether local is always better, but whether the requested feature actually requires the file to leave the device.

For a compact wobble effect, it does not. Keeping the image local makes the tool faster, simpler and more private at the same time.