Images & photos · Image Converter & Compressor
How Web Workers and OffscreenCanvas keep image conversion responsive
· How it works
browser-processing canvas web-workers
Encoding a large image takes real CPU time, and doing it on the main thread would freeze the page. This post explains how Web Workers and OffscreenCanvas move that work off the UI thread and what that architecture means for privacy and for limits.
The tab that would freeze — what happens when a heavy encode runs on the thread that also draws the page
Decoding, redrawing and encoding a batch requires CPU work and decoded pixel memory. If every operation ran in the same event loop that handles controls, progress updates and painting, the interface could stop responding until a file finished. The focused panel therefore creates a module worker lazily when the first conversion begins rather than paying that startup cost for a visitor who never converts.
Responsiveness is an architectural goal, not a promised timing number. Device load, image dimensions, browser implementation and batch composition still determine how fluid the page feels. Verify with representative files on the devices that matter; do not publish a universal conversion duration or claim that a worker makes expensive work free.
The main thread and why it is precious — one thread for layout, input and scripts, and how long tasks block all three
The main thread owns the DOM and the controls a visitor touches. ToolAcre uses it to validate selections, decode briefly for source dimensions, build settings, render status and download results. The batch’s repeated decode, canvas draw and encode loop lives behind `image.worker.js`, allowing progress messages to return between files.
A worker does not eliminate every main-thread task. Each selected file is initially checked and measured in the panel, and results are later turned into previews and download actions there. The design moves the repeated heavy pipeline away from interface ownership while keeping browser APIs and presentation in the context where each belongs.
Web Workers: a second thread with no DOM — what a worker can and cannot touch, and how files travel to it
The worker has no ordinary DOM access. It receives serializable item descriptions, settings and each file’s ArrayBuffer. For every item it builds the same pure conversion plan used by the interface, creates a Blob, executes decode-draw-encode, converts the resulting Blob to bytes and records a per-file failure without abandoning the rest of the batch.
That isolation also shapes error handling. A corrupt file can enter the failures array while later items continue. The worker checks for cancellation between items and reports progress with the current filename. The UI translates a worker timeout into advice to try fewer or smaller images rather than leaving a disabled button with no explanation.
OffscreenCanvas: drawing and encoding without a visible element — how a worker gets its own canvas and calls convertToBlob
`createCanvas` prefers `OffscreenCanvas` when the constructor exists. Inside that path, `encodeCanvas` calls `convertToBlob` with target MIME type and optional quality. The same renderer can also create an HTML canvas and use callback-based `toBlob`, preserving a fallback for contexts where OffscreenCanvas is unavailable.
The fallback is important to describe accurately. OffscreenCanvas is preferred, not the only possible canvas in the source. Likewise, browser WebP encoding is checked by the eventual encode result rather than assumed from decode support. The application promises an error when the requested encoder cannot produce the format, not silent substitution with another MIME type.
Transferables and copies — moving an ImageBitmap or ArrayBuffer to a worker without duplicating tens of megabytes
Before calling the worker, the panel reads each File into an ArrayBuffer and includes those buffers in the transfer list. Ownership moves to the worker instead of cloning every input buffer. After encoding, the worker wraps the Blob bytes in a Uint8Array and registers that backing buffer for transfer on the response path.
This reduces avoidable copying, but decoded images and canvases still occupy memory. `executePlan` closes each ImageBitmap in a `finally` block so its decoded pixels can be released promptly. Transferables, explicit bitmap cleanup and a pixel-budget guard address different sources of pressure; none authorizes an unlimited batch claim.
Why this architecture is also the privacy story — the whole pipeline lives in your tab, and the network panel stays silent
The conversion code calls browser image and canvas APIs without a file-upload request. A unit test guards planning for every supported input-output combination with network access forbidden. The config’s privacy statement is correspondingly narrow: the tool code makes no request carrying the file, pasted text or generated output.
The page itself can still load site assets and disclosed external scripts, so “silent network panel” needs interpretation. Clear DevTools after load and look for a distinctive harmless test filename or payload bytes in new requests. Source review and runtime observation together support a claim about the conversion path; neither turns the entire browser environment into an offline sandbox.
Where the limits come from — memory and canvas caps replace upload caps, so the ceiling is your device
Local processing replaces an upload limit with constraints from input validation, decoded pixels, canvas allocation and available device memory. Each input file is capped at 40 MB by the focused panel. Planned output geometry is fitted to a device pixel budget, and the user receives a warning naming the reduced dimensions when that guard changes the request.
There is no fixed batch count in the config. Twenty small graphics and twenty high-resolution photos are not equivalent allocations. A phone can fail earlier than a desktop. The truthful operational advice is to process fewer or smaller files after a timeout or memory failure, not to publish an unsupported maximum count or megapixel ceiling.
Takeaway: heavy lifting, quiet interface — how the Image Converter & Compressor performs conversions off the main thread on your device
The interface stays quieter because the repeated pipeline runs in a worker, its canvas can be offscreen and large byte buffers travel as transferables. Those are concrete source properties, not marketing shorthand. They explain where work occurs and how progress returns without claiming that every browser schedules it identically.
Test the architecture with the images your workflow actually uses. Watch controls during conversion, confirm per-file progress, inspect failures and check the Network panel for the test marker. ToolAcre’s design gives you observable evidence: a real worker module, measured outputs and local download bytes rather than an opaque remote job.