A browser-only image workflow that actually holds up

The interesting question about a browser editor is not whether it replaces Photoshop. It is which jobs it can absorb completely, so that the desktop suite stops being on the critical path for every small request.

The jobs it absorbs fully

There is a category of work that is 90% of the volume and 10% of the complexity:

• Resizing and cropping for a specific placement.
• Format conversion, with or without flattening.
• Opening a file someone sent, checking it, extracting one layer.
• Quick retouching: remove a blemish, patch a background, straighten a photo.
• Adding or changing a single text layer for a variant.
• Colour tweaks against a client’s brand value.

For all of these, a tab that opens in two seconds and never uploads the file beats an application that needs a licence, an install and a GPU driver update.

The jobs it should not take

Be honest about the boundary, because overreaching is how teams get burned:

• Print production with CMYK, soft proofing and spot colours.
• Documents in the hundreds of layers with gigabytes of pixel data.
• Anything requiring 3D, video, or a plug-in ecosystem.
• Long, multi-day documents that need version control at the layer level.

A sensible split: browser for the fast 80%, desktop for the deep 20%, and a shared folder that both can reach.

The privacy argument is the practical one

With a local editor there is no upload step, so the file never leaves the machine. That single property removes a whole category of questions: client NDAs, unreleased product shots, personal photographs, medical images.

Upload-based converters ask you to trust a stranger’s retention policy. A WebAssembly build asks you to trust your own browser sandbox. For most teams, the second is an easier conversation with legal.

Organising the handoffs

The workflow only works if files can move in and out of the browser without friction:

1. Naming. Keep the same convention as the desktop files (client-placement-variant-width.ext) so the browser output slots into the same folder structure.
2. Layered source stays layered. Export flattened copies for delivery, but write back a PSD when the edit might be revisited.
3. One tab per document. Multiple tabs are the browser’s version of multiple open documents, and they are easier to compare than a single window with tabs inside it.
4. Export presets by destination. Web (WebP, quality 82), slide (PNG), print handoff (PSD + PDF from the desktop suite).

What changes when the editor is a tab

Two behavioural changes are worth expecting:

• Load time becomes a design constraint. The first load pulls the application itself — about 14 MB here — and the second load comes from cache. Save the app tab and keep it open instead of reopening it for each job.
• The browser is the runtime. GPU acceleration depends on WebGPU being available and enabled; a locked-down corporate browser profile may disable it. Check before you make it the team standard.

Try the loop end to end

The fastest way to judge whether this fits is to run one real job through it: open a layered PSD, hide the layers you do not need, export a PNG, and compare it to what your desktop editor produces. Both the PSD to PNG flow and the format comparison give you the specifics; the editor is where the loop runs.