No. I loaded the machine until a 12-megapixel conversion took seven times as long — and the file that came out was byte-for-byte the same one.
Short answer: no. I ran six sessions against the live page with the machine under increasing CPU load — nothing competing, then 1, 2, 4, 8 and 16 busy-loop processes fighting for the same two cores. Every session produced the same 38,078-byte JPG from the small photo and the same 3,177,680-byte JPG from the 12-megapixel one, with identical SHA-256 hashes, and all six downloads landed on disk at 38,078 bytes. What changed was only the wait: 852 ms for the small photo with nothing else running, 5,495 ms with sixteen processes competing; 5,877 ms for the 12-megapixel photo at idle, 41,467 ms at the heaviest load.
The page never froze. Across all six runs the interval between animation frames stayed at a median of 17 ms — about 60 frames a second — including during the 41-second conversion. The longest single gap I saw was 483 ms, and there was not one gap over a second in any run.
How I measured it: today, in Chrome 153.0.8010.54 (headless, Windows, window 1280 × 900) on a two-core machine, driving the live page through the DevTools protocol. I first tried the browser's own CPU throttling and it did nothing measurable — details below — so instead I started real competing processes and let them fight the converter for CPU.
The obvious tool is the DevTools protocol's CPU throttling, which is meant to slow a page down by a chosen factor. On this Chrome it had no effect I could measure. I ran the same 20-million-iteration JavaScript loop at three throttle settings, in a headless window and again in a normal (off-screen) window:
| Throttle setting | Headless window | Normal window |
|---|---|---|
| rate 1 (no throttle) | 33, 27, 29 ms | 66, 37, 47 ms |
| rate 4 | 40, 32, 25 ms | 54, 41, 38 ms |
| rate 20 | 52, 45, 46 ms | 42, 49, 45 ms |
A twenty-fold throttle should have turned a loop that runs in about 30 ms into something near half a second. It stayed between 25 and 52 ms in the headless window, and between 37 and 66 ms in the normal one. So I am not going to publish numbers labelled "4× throttled" — they would be fiction. Everything below is real contention instead: processes that genuinely consume CPU while the converter works.
Each session opened a fresh page and converted both photos once. Usable is when the converter's function exists on the page and the document has finished loading. Frames counts animation frames during the 12-megapixel conversion; the median interval is how smoothly the page kept painting while it worked.
| Competing processes | Page usable | Small photo | 12 MP photo | Frames | Median frame interval | Longest gap | Download |
|---|---|---|---|---|---|---|---|
| 0 | 472 ms | 852 ms | 5,877 ms | 321 | 17 ms | 233 ms | 38,078 B |
| 1 | 433 ms | 768 ms | 5,647 ms | 332 | 17 ms | 67 ms | 38,078 B |
| 2 | 509 ms | 1,383 ms | 9,340 ms | 526 | 17 ms | 267 ms | 38,078 B |
| 4 | 979 ms | 1,891 ms | 16,462 ms | 908 | 17 ms | 417 ms | 38,078 B |
| 8 | 1,434 ms | 3,309 ms | 24,838 ms | 1,443 | 17 ms | 483 ms | 38,078 B |
| 16 | 1,882 ms | 5,495 ms | 41,467 ms | 2,387 | 17 ms | 333 ms | 38,078 B |
From idle to the heaviest load the small photo went 6.45× slower and the 12-megapixel one 7.06× slower. The page took longer to become usable too: 472 ms with nothing competing, 1,882 ms with sixteen. And the frame count climbs simply because the conversion lasted longer — 321 frames while 5,877 ms of work went by, 2,387 frames during 41,467 ms of it, at the same 17 ms interval.
Across all six sessions, including the six extra conversions I ran to press the download button, the small photo's JPG hashed to 93859de257dc44a7… every single time and the 12-megapixel one to 56ee525f012aa19f… every time — the same hashes this site records for those two photos on quiet days. The result area was visible and the error area was hidden in all six sessions; the file label read s1.jpg — 700×476 — 37 KB and its equivalents. Six downloads, six files on disk at 38,078 bytes each.
That is the part worth knowing: CPU speed is not an input to the conversion. The decoder does the same arithmetic whether it takes two seconds or forty, and the bytes it writes are the bytes it writes. A slow machine buys you a longer wait, not a different photograph.
I expected everything to get slower together. It did not. That same 20-million-iteration JavaScript loop, run five times in each session and taking the median, came out at 26, 26, 23, 23, 23 and 23 ms across the six load levels — flat, while the conversion beside it slowed sevenfold.
What I can say from the measurements is where the cost landed: in the conversion, not in the page's own thread. The frame interval stayed at 17 ms the whole way through, so scrolling and repainting were not what paid for the load. The decode is the work that competes for CPU, and it is the work that waits.
I cannot tell you from these numbers exactly how the browser's scheduler divided the two cores between the page and the competing processes — I measured the outcomes, not the scheduling. So I am not going to explain why the loop stayed flat. I am reporting that it did, twice, in two separate runs.
It does not tell you about a phone. Sixteen busy processes on a two-core Windows machine is not the same thing as a low-end handset, and I did not measure one today. What transfers is the shape of the result: the converter has no timeout I hit, no quality it trades away for speed, and no code path that gives up when the CPU is slow. The slowest conversion I measured ran 41,467 ms and finished normally.
I never saw one. My longest wait was 41,467 ms for the 12-megapixel photo under the heaviest load, and the script was prepared to wait up to fifteen minutes before calling a run failed. No session produced an error, and the error area stayed hidden in all six.
No. Same 38,078 bytes and same 3,177,680 bytes at every load level, with matching hashes. Speed is not one of the things the quality setting depends on — the file-size measurements cover what does move the number.
The frame data says yes: median interval 17 ms in all six sessions, the longest single gap 483 ms, and no gap over a second anywhere. I measured painting, not clicking — I did not test pressing buttons mid-conversion under load today.
I did not find a floor. Sixteen competing processes on two cores is the worst I made it, and the converter still finished both photos and still downloaded. I have no measurement of a device slower than that, so I will not claim one.
All six downloads landed at 38,078 bytes, named from the source file as usual. The download is the browser saving a file it already has in memory, so it is not the part that competes for CPU.
Because on this Chrome the throttle does nothing: rate 20 left a 25 ms loop running in 31–51 ms. I would rather publish contention I can demonstrate than a number the tool never actually produced.
Try it: open the converter, start something heavy on your machine, then convert a photo — the wait grows, the file does not change.
First published: 7 October 2026