How These Tools Work

Every claim on this site about "nothing is uploaded" is a specific, checkable architectural fact, not a marketing line — you can open your browser's DevTools, watch the Network panel, and run any tool here to confirm it yourself: zero requests. This page explains exactly what runs where, tool by tool, and where the real limitations are.

The shared engine

All four tools are built on the same small shared script, imgcore.js, which provides three things every tool needs: a drag-and-drop file handler, a canvas-based image loader/re-encoder, and a lightweight in-browser ZIP writer for batch downloads. That ZIP writer is worth explaining because it's a genuinely unusual thing to build client-side: it implements the ZIP file format's local-file-header, central-directory, and end-of-central-directory records directly in JavaScript, including a hand-rolled CRC32 checksum table, and produces a stored (uncompressed) ZIP — no compression library needed, since the images inside are already compressed by their own format. That's how "download all as ZIP" works without ever touching a server: the ZIP itself is assembled byte-by-byte in your browser's memory.

Timestamp tool: reading the real capture date

The timestamp tool auto-detects each photo's real capture date by reading its EXIF DateTimeOriginal field directly — this is done with a hand-written binary parser (no library) that walks the raw JPEG byte structure: it checks for the JPEG start-of-image marker, finds the APP1 segment, confirms the embedded "Exif" header, determines the byte order (little- or big-endian) from the TIFF header, then walks the IFD entries looking for tag 0x9003 (DateTimeOriginal) — falling back to tags 0x9004 (DateTimeDigitized) or 0x0132 (DateTime) if needed, and following the Exif sub-IFD pointer (tag 0x8769) if the date lives there instead. If no EXIF date is found — common for screenshots, scans, or already-edited images — the tool falls back to the file's own modified date, and lets you set one manually. Once it has a date, the stamp itself is drawn as text onto a <canvas> over a copy of the image, styled and positioned per your settings, then exported as a new JPG. The original file and its metadata are never touched.

HEIC to JPG: the one tool with an extra local step

HEIC isn't a format a plain <canvas> can decode natively in most browsers, so the HEIC to JPG tool adds one step: a WebAssembly build of libheif (via the heic2any library) decodes the HEIC file locally, in-browser, into a plain image. From there it rejoins the same pipeline as every other tool — drawn onto a canvas, re-encoded to JPG/PNG/WebP at your chosen quality. The WASM decoder is a few megabytes and downloads once on first use (a static file from this site, not a per-image upload), after which the tool keeps working offline.

Remove EXIF and Compress Image: the same core trick

Both the Remove EXIF and Compress Image tools rely on a simple, useful fact about how canvases work: drawing an image onto a <canvas> and exporting it with canvas.toBlob() produces a brand-new file that carries none of the original's EXIF metadata — that's not a special stripping step, it's just how the browser's canvas export works. Remove EXIF uses this directly: redraw, export at high quality (0.95), done — GPS, camera model, timestamps, all gone, pixels unchanged. Compress Image adds two extra parameters before that same export: an optional resize (scaling the canvas dimensions down to a max width/height before drawing) and your chosen quality value (0.3–1.0) passed straight to canvas.toBlob().

What this architecture can't do

Being fully client-side is a real trade-off, not a free upgrade, and it's worth stating plainly where it falls short:

• No server-side fallback. If your browser can't decode a file (a corrupted image, an unusual codec), there's no server to try harder — the tool simply fails on that file and moves to the next in a batch.
• Memory-bound batches. A very large batch of high-resolution photos is limited by your own device's available memory, not by an artificial upload cap — on a low-memory device, an enormous batch can be slower or need splitting into smaller runs.
• No metadata is written back. The timestamp tool draws a visible stamp; it does not edit the EXIF date field itself. If you need the underlying metadata changed rather than a visible stamp added, this tool doesn't do that.
• Requires a modern browser. Canvas and (for HEIC) WebAssembly support is near-universal today, but very old browsers won't run these tools at all.

Why build it this way at all

The honest reason is privacy by construction, not just by policy: a server-based version of any of these tools would be simpler to build, but it would necessarily mean your photos — potentially insurance documentation, personal images, or anything with sensitive GPS data — pass through a server we operate, even briefly. Building everything client-side removes that step entirely; there's no server code path that ever sees your image, which means there's also no server log, cache, or backup that could ever contain one. See the privacy policy for the plain-language version of this same commitment.