I set out to switch the GPU off and measure the difference. I could not: the machine I test on has no hardware acceleration to begin with. So this is what software-only rendering actually looks like — and the converter works fine in it.
Short answer: the converter does not need a GPU. But I have to be straight about what I could and could not test: I never managed to compare "hardware acceleration on" against "hardware acceleration off", because this machine reports software rendering in every configuration I tried — including a normal, visible browser window with default settings. There was nothing to switch off.
What I measured today (15 October 2026, Chrome 155.0.8059.40): 32 real conversions across four Chrome setups on the live site. In all four, the small photo came out as 38,078 bytes and the 12-megapixel file as 3,177,680 bytes, with the same SHA-256 I get on every other run. Canvas 2D worked in all four; WebGL was unavailable in all four. Hardware acceleration was never in play, and the conversion never noticed.
Before running anything I asked Chrome to describe its own graphics stack. It reports two graphics devices, both named Microsoft Basic Render Driver at driver version 10.0.28000.3231. The display type is ANGLE_D3D11_WARP — WARP being Windows' software rasteriser. Direct3D 12 feature level: Not supported. DirectML: Not supported. Zero driver bug workarounds.
And the feature status it reports:
| Feature | Status reported |
|---|---|
| 2D canvas | unavailable_software |
| GPU compositing | disabled_software |
| Rasterization | disabled_software |
| WebGL | unavailable_software |
| WebGPU | unavailable_software |
| WebNN | unavailable_software |
| Video decode / encode | disabled_software |
| OpenGL | disabled_off |
That is the answer to "does it still work with hardware acceleration off" on this machine: there is no "on" state here. Every measurement on this site that I have published — the file sizes, the pixel comparisons, the timings — was already produced under software rendering.
I ran four configurations anyway, in case one of them behaved differently. Each one loaded the live page, converted the 41,465-byte photo five times and the 11,084,868-byte file three times:
| Setup | Page ready | Small photo, median | 12 MP, median | Output |
|---|---|---|---|---|
| Headless, default flags | 1,441 ms | 373 ms | 8,015 ms | 38,078 B / 3,177,680 B |
Headless, --disable-gpu | 1,614 ms | 305 ms | 7,920 ms | 38,078 B / 3,177,680 B |
| Headless, GPU + accelerated 2D canvas + GPU rasterization all disabled | 997 ms | 224 ms | 8,039 ms | 38,078 B / 3,177,680 B |
| Visible window, default flags | 745 ms | 160 ms | 7,144 ms | 38,078 B / 3,177,680 B |
All four reported the same feature status — gpu_compositing: disabled_software, rasterization: disabled_software, webgl: unavailable_software — so these rows are not a hardware-versus-software comparison. They are four different software paths, and all of them produced the same two files.
This is the part that matters if you are wondering whether a GPUless machine will give you a different picture. It will not:
| Source | Output in all four setups | Page's own size line |
|---|---|---|
| 41,465 B, 700 × 476 | 38,078 B, SHA-256 93859de257dc44a7… | g1.jpg — 700×476 — 37 KB |
| 11,084,868 B, 4032 × 3024 | 3,177,680 B, SHA-256 56ee525f012aa19f… | g6.jpg — 4032×3024 — 3103 KB |
Those are the same two hashes this site has produced on every run I have published. The individual run times did vary — the small photo ranged from 116 ms to 1,593 ms across all runs — but the bytes did not, in any setup.
I read the decoder this site ships, all 2,999,737 bytes of it, and counted the calls that would reach for a GPU: WebGL 0, webgl 0, OffscreenCanvas 0, navigator.gpu 0, GPUAdapter 0, requestAdapter 0, SwiftShader 0. What it does use is ordinary 2D canvas: getContext appears twice, createImageBitmap once, toBlob once, and the word canvas sixteen times. The homepage source itself contains none of those GPU names at all.
I also asked the live page directly which canvas contexts it could open: 2d succeeded, while webgl, experimental-webgl, webgl2 and bitmaprenderer all came back false. A canvas that I filled with red and read back returned the pixel [255, 0, 0], which is the honest proof that 2D drawing works even with no GPU behind it.
One detail worth reporting rather than glossing over: navigator.gpu exists as an object on this page, so the WebGPU API is present in the browser, but Chrome's own feature status for WebGPU is unavailable_software. The API being defined is not the same as the API having hardware to run on.
I want to be clear about the limits of this page, because the obvious question — "would it be faster with a real GPU?" — is one I cannot answer from this machine:
3,918 ms.If you are converting HEIC files on a machine without a GPU — a virtual machine, a remote desktop session, an old laptop with a blacklisted driver, or a browser that has fallen back to software rendering — the converter works, and the JPG you get is the same file you would get anywhere else. Nothing about the output depends on graphics hardware.
The machine that produced every measurement on this site has 2 CPU cores and reports 4 GB of device memory. It has no GPU. It has converted thousands of files here.
No. Every conversion I have ever run on this site — including all 32 today — happened with GPU compositing, rasterization and WebGL all reported as software or unavailable, and the outputs are byte-identical to each other.
I have not measured one, so I will not promise it. What I can say is that the encoding path is 2D canvas plus the browser's JPEG encoder, and the decoder on this page contains no GPU calls at all, so there is no route by which a GPU would change the pixels.
No. The page never asks for a WebGL context — the decoder has zero references to it — and the conversion finished normally in all four setups where WebGL was unavailable.
They are three- and five-run samples on a two-core machine, and the first conversion of each file is much slower than the rest. I would not read a ranking into them. The 12-megapixel medians sat between 7,144 ms and 8,039 ms, which is a narrow band compared with the spread between individual runs.
Yes — type chrome://gpu into the address bar and look at the feature status list. That is the same information I read programmatically here. If you see hardware acceleration enabled and want to compare against my numbers, everything on this page is a software-rendering baseline.
chrome://gpu and note whether your features say hardware or software.If your machine does have hardware acceleration and you are curious whether it makes a difference, that is the experiment I could not run.
Try it: open the converter and convert a photo — no graphics hardware required.
First published: 15 October 2026