No. I converted the same photo at seven zoom levels today — 50%, 75%, 100%, 125%, 150%, 200% and 300% — and every single one produced the same 38,078-byte file with the same SHA-256 hash, at 700 × 476. The 12-megapixel photo came back as 3,177,680 bytes at 50%, 100% and 300%, again with one hash. Zooming while a conversion is already running changes nothing either: I switched from 100% to 300% and to 50% one and a half seconds into a 12-megapixel conversion, while the spinner was still up, and both still produced that same file. What zoom does change is what you can see and what you can reach — the preview grows from 250 × 170 screen pixels at 50% to 1,014 × 690 at 300%, and at 300% the upload box falls below the fold, so the page looks like it lost it.
Short answer: browser zoom has no effect whatsoever on the file. Across 25 conversions today at seven zoom levels, the 700 × 476 test photo (41,465 bytes) always came back as 38,078 bytes with one hash, and the 12-megapixel photo (11,084,868 bytes) always came back as 3,177,680 bytes with another. Two distinct files, 25 conversions, no third variant.
Changing zoom mid-conversion does nothing. I loaded at 100%, started a 12-megapixel conversion, waited until the spinner had been up for 1.5 seconds, then switched the zoom — to 300% in one run and to 50% in another. Both finished with 3,177,680 bytes and the same hash as every other run. Zooming after the conversion is likewise harmless: the finished JPG stayed 38,078 bytes with the same hash through a 300% step, a 50% step and back to 100%.
What zoom does change is the interface. Zooming in shrinks the CSS viewport, so the page reflows: the upload box is 714 px wide at 100% but 338 px wide at 300%, and at 300% it sits 333 px from the top of a viewport only 300 px tall — out of sight until you scroll. The preview of the same 700 × 476 image occupies 250 × 170 screen pixels at 50% and 1,014 × 690 at 300%. Same image, same file, very different screen.
How I measured it: today, in Chrome 154.0.8037.99 on Windows, against the live page, driving a real browser over the DevTools protocol. Zoom was reproduced the way Chrome itself does it: the window stays 1,280 × 900 device pixels, the CSS viewport becomes 1,280 ÷ zoom by 900 ÷ zoom, and devicePixelRatio becomes the zoom factor. I confirmed the emulation took hold at every level by reading the viewport size and the pixel dimensions of real screenshots.
Each row is a fresh tab, loaded at that zoom, converting the same 41,465-byte photo once. "Screen pixels" is the pixel size of a real screenshot cropped to the preview element — that is what your display actually lights up.
| Zoom | CSS viewport | devicePixelRatio | Upload box | Preview (CSS / screen px) | Conversion | Output |
|---|---|---|---|---|---|---|
| 50% | 2,560 × 1,800 | 0.5 | 288 px down, 714 px wide | 500 × 340 / 250 × 170 | 1,025 ms | 38,078 B |
| 75% | 1,707 × 1,200 | 0.75 | 288 px down, 714 px wide | 500 × 340 / 375 × 255 | 1,491 ms | 38,078 B |
| 100% | 1,280 × 900 | 1 | 288 px down, 714 px wide | 500 × 340 / 500 × 340 | 792 ms | 38,078 B |
| 125% | 1,024 × 720 | 1.25 | 288 px down, 714 px wide | 500 × 340 / 625 × 425 | 1,002 ms | 38,078 B |
| 150% | 853 × 600 | 1.5 | 288 px down, 714 px wide | 500 × 340 / 750 × 510 | 1,228 ms | 38,078 B |
| 200% | 640 × 450 | 2 | 249 px down, 551 px wide | 382 × 260 / 764 × 520 | 1,513 ms | 38,078 B |
| 300% | 427 × 300 | 3 | 333 px down, 338 px wide | 338 × 230 / 1,014 × 690 | 1,368 ms | 38,078 B |
Every one of those seven files hashes to 93859de257dc44a7ff3dc41eb965d07ff84c8630ec8a3db44e24e89120713c81. The bigger photo tells the same story: 5,467 ms and 3,177,680 bytes at 50%, 5,475 ms and the same bytes at 100%, 5,677 ms and the same bytes at 300% — one hash, 56ee525f012aa19f42998a4edc7a23a3d37f1fae975b649e4e6ba990b667b003, three zoom levels.
The conversion times carry no signal about zoom. They run from 792 ms to 1,513 ms for the small photo with no ordering by level — the fastest was 100% and the slowest was 200% — and the 12-megapixel runs differ by 210 ms across a six-fold difference in zoom.
Two more experiments, because "does zoom matter" is really two questions. The first: if the page is mid-conversion and you zoom, does the run change? I loaded at 100%, handed the page an 11,084,868-byte photo, waited 1,500 ms — checking that the spinner was still displayed at that moment, so the conversion genuinely was in flight — and then changed the zoom.
| Run | Spinner at 1,500 ms | Zoom switched to | Result | Conversion |
|---|---|---|---|---|
| 12 MP, zoomed in mid-run | visible | 300% | 3,177,680 B, same hash | 7,415 ms |
| 12 MP, zoomed out mid-run | visible | 50% | 3,177,680 B, same hash | 5,967 ms |
The second: once a JPG exists, does zooming touch it? After a normal 100% conversion I stepped the zoom to 300%, then to 50%, then back to 100%, reading the download link's bytes each time: 38,078, 38,078, 38,078, with one hash throughout. The rendered preview resizes; the file behind the link does not.
That is the whole distinction. Zoom is a display transform applied after the image has already been decoded and encoded. The bytes are produced before anything is painted.
This is the one place where zoom actually costs you something, and it only bites at the extreme end. Zooming in shrinks the CSS viewport, so the page reflows around it — and at 300% the upload box ends up below the fold.
| Zoom | CSS viewport | Upload box position | Click without scrolling | After scrolling to it | Horizontal overflow |
|---|---|---|---|---|---|
| 200% | 640 × 450 | 249 px down — visible | file picker opened | file picker opened | none |
| 300% | 427 × 300 | 333 px down — below the fold | 0 file pickers | file picker opened | none |
At 300% the box is 333 px from the top of a viewport 300 px tall, so a click at its coordinates lands outside the window and nothing happens; after scrolling it into view, the same click opens the picker normally. The page never develops a horizontal scrollbar at any zoom level I tried — the layout squeezes instead, which is why the box narrows from 714 px to 338 px between 100% and 300%.
Note that this is a different failure from the one in the keyboard measurement, where the box cannot be reached by tabbing at any zoom. Here it is simply off-screen, and a scroll fixes it.
The reason is visible in the source. In today's home page — 13,924 bytes — and in the decoder script it loads — 2,999,737 bytes — the strings devicePixelRatio, visualViewport, zoom, matchMedia, innerWidth and getBoundingClientRect each occur 0 times. Nothing in either file asks how big the window is or how the page is scaled.
The pipeline is: your file goes in as a blob, the decoder decodes it, the result is drawn and re-encoded with canvas.toBlob at a fixed quality, and a single object URL is handed to both the preview and the download link. There is no step where a layout measurement could enter the arithmetic — which is also why the device-pixel-ratio measurement found the same immunity, and why the output is reproducible byte for byte across days in the deterministic-conversion measurement.
No. The output was 38,078 bytes at 700 × 476 at every level from 50% to 300%, and 3,177,680 bytes at 4,032 × 3,024 for the 12-megapixel photo at 50%, 100% and 300%. Zoom changes the display, not the file.
Nothing changes. I switched to 300% and to 50% one and a half seconds into 12-megapixel conversions, with the spinner still up, and both produced the usual 3,177,680 bytes with the usual hash.
Because the same 700 × 476 image is drawn into a box the browser scales: 250 × 170 screen pixels at 50% zoom, 500 × 340 at 100%, 1,014 × 690 at 300%. Those are real screenshot measurements of the preview area, and they say nothing about the file, which is described in what is inside the JPG.
At 300% in a 1,280 × 900 window, where the CSS viewport is only 427 × 300 and the box sits 333 px down — below the fold. Scrolling brings it back, and clicking then works normally. At 200% it is still visible at 249 px.
No horizontal overflow appeared at any of the seven levels. The layout reflows instead: the upload box narrows from 714 px at 100% to 551 px at 200% and 338 px at 300%.
I could not establish that. The protocol call meant to emulate visual zoom reported success but changed nothing I could measure — full-page screenshots stayed 1,280 × 900 and visualViewport.scale stayed 1 at 1.5×, 2× and 3× — so everything here is keyboard-style page zoom only.
Three things. I did not press Ctrl and + on a real keyboard; I reproduced what Chrome does when you do — CSS viewport divided by the zoom factor, devicePixelRatio set to it — and verified it took effect by reading the viewport and measuring screenshots, but it is not literally the same input path. Visual zoom, the two-finger or Ctrl+scroll kind, I could not reproduce at all: the emulation call returned without error yet left every measurement unchanged, so I make no claim about it. And this is one browser on one machine; I did not test Safari or Firefox zoom, or a phone.
Try it: convert a photo, then zoom the page to 300% and back — the download will still be the same file, byte for byte.
First published: 11 October 2026