Skip to main content
PhotoEditor

( Architecture explained )

How your photo is processed locally

This map separates the pixel path inside the browser from technical, measurement, or advertising connections the page may make.

Image path

The arrows below represent the functional sequence observed in the editor. Each card describes a different responsibility.

  1. 1. You choose the image

    The browser receives the file through the picker or drop area. The page validates its type and attempts to decode its pixels.

  2. 2. The browser retains the work

    Studio files and adjustments may remain in IndexedDB; preferences and temporary flow data use browser storage.

  3. 3. Workers process pixels

    Adjustments, thumbnails, and exports are calculated locally. Canvas displays the preview; it is not proof of final-output resolution.

  4. 4. The batch becomes a file

    Individual results are bundled by a ZIP library packaged with the project, without fetching ZIP code from a CDN during export.

  5. 5. The browser starts the download

    A temporary in-memory address is created for the image or ZIP. The new copy is saved through the browser download mechanism.

External page connections

Local processing does not mean the entire page works without a network. This distinction avoids an absolute privacy promise.

Storage and deletion

IndexedDB lets the studio recover files and adjustments across operational routes. localStorage holds preferences such as consent and theme; sessionStorage carries temporary export data. The browser and its storage policies determine when this data may be removed.

The complete legal description, categories, and available choices remain on the Privacy and Cookies pages.

Verify it yourself

MethodologySee how capabilities and claims are tested.Batch benchmarkReview results, ranges, and raw data.Test the batch editorRun the local workflow with your own images.

Architecture details: Workers, Canvas, and TypedArrays

PhotoEditor.sbs separates interface rendering from image manipulation using dedicated Web Workers. When an image is opened, the main browser thread decodes the file into an ImageBitmap, extracts its ImageData, and transmits the underlying ArrayBuffer across thread boundaries. This architecture ensures that sliders for exposure, contrast, temperature, and curves remain responsive even when computing transformations across millions of pixels.

Color transformations operate directly on 8-bit clamped typed arrays (Uint8ClampedArray). For example, tone curve lookups and color channel mixers iterate across flat memory layouts with hardware-level integer clamping, preventing pixel overflow artifacts without costly floating-point conversion overhead. Previews are drawn to high-density HTML5 Canvas surfaces, matching the physical display aspect ratio while retaining full source resolution for the final export pass.

Memory reclamation is carefully managed during long editing sessions. When switching photos or completing a batch export, intermediate object URLs are immediately released using URL.revokeObjectURL(), and stale buffers are garbage-collected. This local lifecycle prevents common browser tab crashes caused by memory accumulation.

Questions about local processing

Does 'in the browser' mean the editor runs without internet?
No. The webpage assets (HTML, stylesheets, scripts, and fonts) must be fetched from the hosting server over the network when opening the tool. What remains local to your device are your actual photo files and pixel buffers.
Is my photo deleted when I close the browser tab?
Session photos are temporarily retained in your browser's local IndexedDB storage so you do not lose progress if the page reloads. This data remains on your physical disk under your browser profile; loading a new batch of photos replaces the prior session.
Why can large batches cause browser memory pressure?
Because decoded pixel bitmaps expand substantially beyond compressed file sizes. A compressed 2 MB JPEG photo can easily expand into 40 MB of raw uncompressed RGBA pixel buffers in memory. A batch of 20 high-resolution photos can quickly reach browser tab heap boundaries.
How can I independently verify that photos are not uploaded?
Open your browser's Developer Tools (F12 or right-click Inspect), switch to the Network tab, filter by Fetch/XHR, and edit or export an image. You will observe that zero HTTP POST or PUT requests containing image binary payloads are dispatched to any server.
What external network connections does the page establish?
Static asset delivery via Vercel CDN, performance telemetry (Speed Insights / Analytics) if accepted in privacy preferences, and Google AdSense ad scripts if consent is given. No image pixels or file metadata are included in any telemetry payload.
How can I strip sensitive EXIF and GPS data before sharing?
The editor discards EXIF headers and GPS coordinates by default during canvas rasterization. For dedicated metadata cleaning, use our Remove photo metadata tool.