Architecture and privacy

What browser-local conversion means in this project

Follow files from browser selection through local parsing, image decoding, SpriteProject validation, selected-output encoding, and download.

Browser-local conversion means source artwork is read, parsed, decoded, transformed, previewed, and exported by code running in the browser tab. It does not mean the page makes no network requests at all: Cloudflare still serves the public HTML, CSS, JavaScript, and other static assets needed to load the application.

The conversion pipeline

  1. The visitor selects files through a browser file input or drag-and-drop. JavaScript receives File objects; selection alone does not upload them.
  2. The chosen importer reads bytes or text with File, Blob, and typed-array APIs. Format signatures and resource limits are checked before expensive work.
  3. PNG-backed formats use local image decoding and canvas when needed. Project-owned GIF and APNG logic parses animation structures before producing RGBA snapshots.
  4. The importer creates a source-independent SpriteProject containing frames, supported layers, and cels.
  5. Validation checks frame references, dimensions, durations, layer properties, RGBA byte lengths, and structures the exporter relies on.
  6. The preview reads the same model. Duration and layer-name edits update local state.
  7. The selected exporter creates the requested output bytes in memory. Blob URLs offer the resulting file or files as browser downloads.
selected local File(s) ↓ local parser / decoder validated SpriteProject ↓ preview and optional edits selected output bytes ↓ Blob URL browser download

What the network is used for

Opening the production site requests static resources from Cloudflare Pages. The host may receive ordinary web request metadata such as IP address, user agent, referrer, requested path, and timing according to its infrastructure and configuration. Those requests are separate from conversion and should not contain selected artwork, embedded project pixels, source metadata, or the generated output files.

The project has no conversion backend, upload endpoint, database, cloud artwork store, or remote image-processing fallback. If a browser lacks a required local API or reaches a memory limit, the importer reports a failure; it does not send the file elsewhere.

Format-specific local work

Simple PNG inputs are signature-checked and decoded with browser image facilities. Piskel and Pixilart JSON is parsed locally and embedded PNGs are decoded in the tab. ZIP-based OpenRaster, Pixelorama, and Krita projects validate archive entries and decompress supported content locally. PSD parsing and channel decoding also stay in the page. The GIF importer owns its LZW and compositing logic, while APNG parsing validates chunks and uses local bounded decompression.

Why browser memory can exceed file size

Compressed input size is not decoded cost. One RGBA image needs roughly width × height × 4 bytes. That amount can multiply by frames and layers, while source bytes, decoded images, canvas copies, preview state, and output bytes coexist. A 1,024×1,024 RGBA cel is about 4 MiB before JavaScript and browser overhead; one hundred full-canvas frames approach 400 MiB for cel pixels alone.

Importers enforce format-specific limits rather than returning partial projects. If a conversion is too large, reduce canvas, frame, or layer count, split the work, or use a less memory-constrained desktop environment. There is no hidden server fallback.

External links are separate actions

Following the GitHub repository or optional support link navigates to another service governed by its own policy. Attaching a file to an issue, email, chat, cloud drive, or validator is also separate from browser-local conversion. Use a newly created minimal reproduction instead of private artwork when reporting a problem.

Advertising status and boundaries

Public pages contain Google AdSense account-verification metadata, but the current repository does not load a live AdSense script or render ad units. The privacy policy describes how the site would need to handle third-party advertising if it is activated later. Advertising must remain separate from file selection, conversion, errors, and downloads.

How to verify the boundary yourself

  1. Load the production page and allow its static assets to finish.
  2. Open the browser Network panel and clear the request list.
  3. Convert a tiny synthetic PNG sequence or project fixture that contains no private work.
  4. Confirm no new request body or URL contains the source file, its embedded metadata, or the generated output.
  5. Remember that clicking an external link or enabling future third-party scripts changes the set of requests and should be reviewed separately.

For the representation created in the middle of this pipeline, see the SpriteProject data-model article. The full policy is at Privacy.