The menu stays live, but the setting was already read. The JPG comes out at the quality you started with, not the one you switched to.
Short answer: nothing happens to the conversion that is already running. The quality value is read once, at the moment your file is handed to the decoder, and everything after that — the spinner, the result, the download — belongs to the setting you had when the file arrived. Switching the menu mid-run changes the next photo, not the one in flight. It also does not re-encode a result you already have.
What I measured today, on this site in Chrome 153: I started a 12-megapixel conversion at 85% and switched the menu to 95% while the spinner was up, 1,500 ms in. The output was 3,177,680 bytes — the same file this converter produces for that photo at 85% — while the same photo converted start-to-finish at 95% weighs 6,115,723 bytes. The call into the decoder carried quality: 0.85, not the new value. I tried four start/target combinations and the output matched the starting setting in all four.
So if you catch yourself changing the setting too late: the run you are watching will finish at the old quality, and the honest fix is to redo it, which costs one more full conversion.
Before the timing questions, the facts about the control itself, read off the live page:
<select id="q"> — 1 select on the whole page, with a real <label for="q"> reading "Quality".High — 95%, Good — 85% and Smaller file — 75%. There is no custom slider and no numeric field.Those three settings map to real differences in the file you get. Same 12-megapixel photo (4,032 × 3,024), one conversion each, setting chosen before the file was dropped:
| Setting | Output | Page showed | Time |
|---|---|---|---|
| 0.75 — Smaller file | 1,938,206 bytes | 4032×3024 — 1893 KB | 7,774 ms |
| 0.85 — Good (default) | 3,177,680 bytes | 4032×3024 — 3103 KB | 4,971 ms |
| 0.95 — High | 6,115,723 bytes | 4032×3024 — 5972 KB | 5,346 ms |
And for an ordinary 700 × 476 phone photo, the same three settings: 30,231, 38,078 and 57,617 bytes (page shows 30 KB, 37 KB and 56 KB), in 206, 201 and 113 ms.
For each run I loaded the page fresh, set the starting quality, dropped the file, waited 1,500 ms — the spinner was visible in every case — then switched the menu to a different setting and waited for the result:
| Started at | Switched to (1,500 ms in) | Output | Matches |
|---|---|---|---|
| 0.85 | 0.75 | 3,177,680 bytes | the starting setting (0.85 = 3,177,680) |
| 0.85 | 0.95 | 3,177,680 bytes | the starting setting (0.95 would be 6,115,723) |
| 0.75 | 0.95 | 1,938,206 bytes | the starting setting (0.95 would be 6,115,723) |
| 0.95 | 0.75 | 6,115,723 bytes | the starting setting (0.75 would be 1,938,206) |
Four out of four landed on the starting value. The switch is not queued, not averaged and not applied late: the value that reaches the decoder is the one that was in the menu when the file arrived.
No. I ran the same 0.85 → 0.75 switch at three different moments, each with the spinner still up and the conversion not finished:
All three equal the 0.85 output, and all three recorded quality: 0.85 in the decoder call. The conversion times for those runs were 5,851, 5,715 and 5,355 ms, so the switch did not perturb the work either.
Rapid switching behaves the same way. On one run I moved the menu 0.85 → 0.95 → 0.75 → 0.95 at 600 ms intervals: the output was 3,177,680 bytes — the value at drop time — and the conversion took 5,728 ms. Afterwards the menu was sitting on 0.95, so the next photo would come out at that setting unless you move it back.
One more detail that explains why: dispatching a change event makes no difference. I switched the value twice, once firing the event and once just setting the property, and both runs produced 3,177,680 bytes. The page reads the menu's current value at the moment it starts the conversion; it does not listen for changes.
I checked the control 1,200 ms into a conversion, while the spinner was showing: disabled was false, pointer-events was auto, opacity was 1, the cursor was pointer, and all 3 options were still there. The upload area was still displayed as well. Nothing dims, locks or warns you — which is exactly why a mid-run change feels like it should do something. It does, just not to the photo that is already being decoded.
Two results from the same page:
4032×3024 — 3103 KB, the download link still pointed at the same blob, and the download name was untouched. The finished JPG only ever exists in memory, so there is nothing to re-encode — if you reload at that point you lose it entirely, which is what the reload measurements are about.So the setting is a "from now on" switch, not a "redo this" switch.
On a big file that redo is the expensive part; on a 700 × 476 phone photo it cost 101 ms in today's run, so for single photos it is cheaper to redo than to think about.
No. I counted 3 options on the live page — 95%, 85% and 75% — and a single <select>. There is no slider, no numeric input and no hidden fourth option.
I cannot claim that from today's three runs: 7,774 ms at 0.75, 4,971 ms at 0.85 and 5,346 ms at 0.95 is not an ordering. A larger measurement — 200 files at three settings — found quality changed file size, not speed, and today's numbers do not contradict that.
No. The info line, the download link and the blob behind it all stayed as they were; only the next conversion picked up the new value.
No. In the run where I switched settings after the result, the download name was still the file's own name with .jpg on the end. How that name is built — including what happens to a file that already ends in .jpg — is measured separately in the iPhone format article.
That is a design choice on the page, and today's measurements only tell you what it does, not why. What I can say is that the value is captured before the decode starts, so no later change reaches it.
Try it: open the converter, pick 85%, drop a photo in, switch to 95% while the spinner is up, and compare the size you get with a clean 95% run.
First published: 5 October 2026