PROCESSING MODEL
Local Processing and Format Limits
ImageConvert separates supported browser conversions from formats that need heavier processing so users know what happens locally before choosing files.
Supported browser conversions
Supported browser conversions handle image inputs and exports directly on the device. This is the preferred path because it is fast, private and does not require an account.
Current supported export targets are JPG, JPEG, PNG, WEBP, AVIF, JFIF and ICO when the browser or local encoder can safely produce the requested file type. HEIC/HEIF, TIFF/TIF, EXR, HDR, static GIF and static APNG inputs can also export locally to JPG, JPEG, PNG and WEBP through browser-loaded decoders/parsers or browser image decoding. EXR/HDR output is tone-mapped to standard dynamic range previews, with byte-proven AVIF/JFIF/ICO/GIF server outputs for EXR/HDR still images. ICO output is generated as a multi-size favicon container from browser-decodable image inputs. Animated GIF/APNG files are detected and refused rather than flattened.
Formats that need more processing
RAW camera formats beyond supported Sony ARW, AI/EPS, OpenEXR variants beyond browser-supported tone-mapped JPG/PNG/WEBP and other HDR variants (beyond Radiance HDR) and animation-preserving GIF/APNG conversion still need additional processing before they can be offered safely. HEIC/HEIF, TIFF/TIF and EXR/HDR to JPG/PNG/WEBP now use local browser decoders/parsers, EXR/HDR to AVIF/JFIF/ICO/GIF uses byte-proven temporary server routes, static GIF/APNG conversion is local with animation refusal, ICO favicon output is local for browser-decodable image sources.
Future heavier processing may run through WASM in the browser or isolated server workers with clear file-size limits, retention rules and error handling.
What may leave the device
Normal page requests, analytics events and support emails leave the device. Source image bytes for supported browser conversions are not intentionally uploaded by the converter flow.
If ImageConvert ever adds upload-based processing for a heavier workflow, that page must say so before file selection and explain retention, deletion timing, accepted formats and maximum size.
Browser memory and WASM limits
Some local decoders and encoders load WebAssembly or worker files from ImageConvert, then process the selected file in the browser. Large images can still fail because the browser must decode pixels and allocate a canvas before export.
When dimensions, file size or batch count are unsafe, ImageConvert should stop with a clear message instead of allocating an extreme canvas or pretending a download is valid.