Riducly guide
How Riducly processes images
A transparent explanation of local and transient server processing, from file selection to download, including storage, metadata, security and current limits.
Two processing paths, selected before upload
Riducly supports on-device processing and transient server processing. Desktop browsers default to the on-device path. Mobile browsers default to the server path because decoding and re-encoding several high-resolution photos can exhaust limited browser memory or freeze the page. The processing-location control shows the active choice before files are added and lets you change it when the alternative is available. The selected path applies to the current batch. This distinction matters: Riducly does not claim that every file always remains on the device, and the interface should never hide which path will handle the images.
What happens during on-device processing
After you select an image, the browser validates its type and size, decodes its pixels and creates a temporary preview. Compression or conversion then runs in browser memory with the chosen format, quality mode and maximum dimensions. Completed output is represented by an in-memory Blob and a temporary object URL until you download or remove it. Riducly does not intentionally send image bytes to its application server in this path. Closing or resetting the workflow releases those temporary browser objects; your downloaded copy remains wherever your browser saved it. Browser download behavior and local file retention remain under the control of your device.
What happens during transient server processing
When server processing is selected, each image is transmitted over HTTPS to the compression endpoint and handled sequentially. The application validates the request, applies current guest or account limits, decodes the file in process memory, creates the requested output and returns it in the same response. The implementation does not write input or output image files to disk, PostgreSQL, Cloudflare R2 or Backblaze B2. Memory is released after the request completes or fails. Operational logs record safe error categories and request identifiers, not file contents, filenames or image pixels. A failed image is not silently retained for later processing.
Formats, metadata, transparency and animation
Riducly decodes the source into pixels and encodes a new file. The destination follows the capabilities of the selected format rather than copying the original container. JPG cannot retain transparency; PNG and WebP can. HEIC and HEIF can be read, but Riducly does not produce HEIC output. Embedded EXIF, location, camera and other source metadata are not copied into re-encoded files. The current workflow treats images as still frames, so animated WebP motion and iPhone Live Photo components are not preserved. Conversion can change file size in either direction, and repeated lossy encoding can accumulate artifacts without restoring missing detail.
Accounts, limits and anonymous service counters
You can start without an account, but guest file, batch and server-request limits protect the service. The uploader displays the current allowance, and a free account can increase limits and enable parallel local work when supported. Riducly maintains fully anonymous aggregate counters for accepted uploads, completed outputs and downloaded results. These counters contain only a page category, event name and number of images; they do not store an advertising identifier, browsing profile, filename, image content or per-user history. They support reliability and conversion measurement without loading a third-party analytics script. Optional written feedback is separate and is submitted only when you choose to send it.
How to verify the behavior yourself
Choose local processing on desktop, open the browser developer tools and watch the Network panel while processing a small test image: the compression endpoint should not receive the file. Then choose server processing with a non-sensitive test image and observe one compression request returning the generated file. Review the result format, dimensions and measured byte size before downloading. The public privacy and cookie notices describe account, security and retention behavior in more detail. Use disposable images for network testing and report any mismatch between this guide and observed behavior through the published contact channel. If implementation or infrastructure changes, the notices and this guide must be updated together.