Open the settings panel of any local AI tool worth using and you will find two letters doing quiet, important work: the engine badge. It reports which of two very different computing paths your images are actually traveling: the graphics chip or the processor. Same network, same result, same file that never leaves your machine. What differs is the machine part, and the difference is large enough to be worth understanding.
The GPU path: WebGPU
Your graphics card contains thousands of small cores designed to do one thing extremely well: apply the same operation to many pieces of data at once. That is, definitionally, what neural network inference is, millions of small multiplications, none of which depend on each other. WebGPU is the browser's modern, open interface to that hardware, and when a tool reports it as the active engine, your images are being processed by the chip that renders your screen.
The performance gap versus the CPU path is not subtle. On a single image it is commonly five to ten times; on large batches, the gap widens further because the GPU sustains its throughput while the CPU heats, throttles, and fights the rest of the system for memory bandwidth. The GPU path also shares the load correctly: the graphics chip does the math while your CPU stays free for scrolling, tabs, and everything else.
The CPU path: WebAssembly everywhere else
Not every device has a GPU that the browser trusts with compute. Older hardware, unusual drivers, locked-down enterprise machines, and conservative browser configurations all land in the same place: the fallback. Here the network runs as WebAssembly, a compact binary format executing at near-native speed across your CPU cores, parallelized where possible. It is genuinely fast for what it is. It is also, relative to the GPU path, slow, and it shares your processor with everything else running on the machine.
The fallback's real value is coverage and dependability. It runs everywhere, it never crashes drivers, and it delivers the identical output; the network does not know or care which hardware is executing it. This is the design's quiet elegance: capability is universal, performance is tiered, and the user chooses the tier by owning hardware rather than by renting someone else's.
The two paths also differ in how they interact with the rest of your machine. The GPU path executes on dedicated silicon with its own memory, so your CPU stays responsive: you can scroll, type, and switch tabs while a large image churns. The CPU path competes directly with everything else running, which means a batch job on an older laptop will make the whole system feel heavier. Neither behavior is wrong; they are the natural consequences of asking a shared resource versus a dedicated one.
Thermals follow the same split. Graphics chips are designed for sustained parallel throughput and typically maintain their clocks through long jobs, while CPUs, being tuned for single-threaded bursts, throttle more aggressively under sustained load. On a phone this distinction is stark: the GPU finishes a single image inside the thermal envelope comfortably, whereas the same job on the CPU path can warm the device enough to trigger clock reduction partway through.
Why the badge reads back instead of assuming
Feature detection alone lies. A browser can report GPU compute support while the driver underneath cannot deliver it; a device can support every required feature except one, discovered only at initialization; and some drivers accept work buffers then execute them on a CPU fallback anyway. The honest implementation asks the runtime which engine it actually committed to after initialization succeeded, not what the specification sheet claims. That is why the badge is worth trusting when it surprises you.
GPU acceleration means the fast path is live, nothing to do. CPU fallback means the GPU path was unavailable or failed initialization, and is usually a driver update or a browser flag away from flipping. DETECTING means the runtime has not reported back yet.
What does not change between engines
Quality. This point is worth stating plainly because it is the assumption users get wrong. The neural network, the entire body of knowledge that produces the result, is identical on both paths. Same weights, same math, same numerical precision for image work. Two devices running different engines produce matching outputs; a side-by-side of a GPU result and a CPU result is indistinguishable. The engine decides the wait, never the work.
Privacy does not change either. Both paths execute entirely on your device, and the CPU path is, if anything, the more obviously local of the two, since everyone can picture their own processor crunching numbers. Neither path has a network interface. Neither path phones home. The engine choice is a performance dial with no privacy dimension at all.
Making the most of both
Practically: enable the GPU path where you can (the enablement guide for your browser takes about two minutes), and treat the fallback as the floor that guarantees the tool still works on the oldest hardware in the house. On machines where the badge reports the CPU path permanently, right-size the workload: 2× scales on modest images remain pleasantly quick even on the fallback, while multi-gigapixel batches belong on hardware with a real graphics card.
The larger lesson hiding in this two-engine design is about what local AI promises in general. Universal capability with tiered performance is exactly the trade modern browsers were built to broker: the software runs everywhere, the hardware sets the tempo, and no user is ever locked out of the feature itself. The badge is small. What it reports, meaning your machine doing the work at the best speed it has, is the whole thesis.
One detail worth knowing if you use several machines: the engine is a property of each device, not of the account. Move a family archive to a laptop and the badge will change; take a notebook to a desktop and it will change again. The same photos and the same settings produce a different wait, and the difference arrives from the hardware under your hand, not from any setting worth changing. This is the final inversion of the cloud model: there, your job was to rent the fastest machine you could, and pay for it. Here, the best machine is the one already in your hands, and the wait it produces is the price tag.
