Why Your Browser Tab Must Stay Open During Large Batch Jobs
HideShot never sends your images to a server for processing. The canvas, memory, and CPU doing the work belong to this tab. Close the tab, suspend the laptop, or aggressive mobile backgrounding — and a long sequential queue can stop mid-run. That is the trade for local privacy.
🔒 Fully local · Runs in your browser · Instant download
HideShot’s pitch is simple: your screenshot never leaves your machine for redaction. Simple does not mean magic. Client-side means the browser tab is the compute environment. There is no background worker on HideShot’s servers finishing job seven while you close the laptop lid.
Sequential multi-file workflow is blur multiple photos at once (one canvas, many passes). Crowded single-file work is how many faces can you blur in one photo. This page is why the tab must stay alive — framed as how local privacy works, not as an apology.
Guide
Server-based redaction can queue jobs you do not see. You close the browser; an email arrives when done. That convenience requires custody of your files on someone else’s disk — even temporarily. HideShot chooses the other architecture: decode image in JavaScript, draw on canvas, encode PNG in JavaScript, trigger download. The event loop, memory allocator, and GPU paths are yours.
What ‘client-side only’ means technically
When you drop a 4000×3000 PNG, the browser allocates a bitmap (width × height × 4 bytes is the rough ceiling before overhead). Cover operations touch pixels in RAM. Export serializes the canvas to PNG — CPU work, not a network round trip. No HideShot API receives the bytes. DevTools Network should not show your image body leaving the origin except ads/analytics requests unrelated to cover.
A ‘batch’ on HideShot is therefore a loop you operate: open image, mark, download, open next. Each cycle repeats decode and encode. Ten large files mean ten memory spikes. The tab holds state — current canvas, undo stack if present — until you navigate away.
Why closing or backgrounding interrupts work
Navigating away or closing the tab destroys the JavaScript realm: canvas gone, in-memory file handles gone, partial work not checkpointed to disk unless you already downloaded. Sleep on a laptop can pause timers and throttle background tabs. Mobile OS kills background web content aggressively — iOS Safari is notorious for unloading inactive tabs.
There is no server-side job ID to resume. Resume means you reopen HideShot and restart from the file you had not finished — the originals on disk are unchanged.
Practical tips for large sessions
- Prefer desktop for queues. More RAM, stable power, less aggressive tab killing. See blur multiple photos at once.
- Pin the tab. Reduces accidental closure; reminds you a queue is active.
- Disable sleep during the run. OS sleep pauses the browser mid-export.
- Download and verify each PNG before loading the next. A crash loses only the in-progress canvas, not finished downloads.
- On mobile, stay in Safari foreground; plug in. Do not switch to Messages mid-batch.
- Close other heavy tabs. Memory pressure triggers kills — the redaction tab is not privileged.
Why this is a feature
The same property that requires an open tab — no server custody — is why privacy-sensitive users pick HideShot for banking screenshots, medical forms, and legal grabs. You are not trusting a vendor’s retention policy for a batch queue. You are spending local CPU time you control. The tab staying open is the visible cost of that control.
Mistakes
Starting twelve 4K files on a phone on battery, then switching apps. Expect to restart.
Assuming ‘it saved’ because the canvas looked done before download clicked. Until PNG lands in Downloads, work is volatile.
Wanting server batch without server custody. Architectures pick one; HideShot picks local.
Queue habit: blur multiple photos at once. Many faces one file: how many faces can you blur in one photo.