Yes — the picture on screen and the download link are literally the same object. But the preview is drawn at half your photo's pixels, the number under it is rounded, and saving the picture instead of downloading it gives you a different file.
Short answer: yes, byte for byte. The converter makes one object URL from the finished JPG and gives that same string to both the <img> on screen and the download link. In seven conversions run today on the live page, the two URLs were the same string every time, fetching them produced the same SHA-256, and the file that landed on disk carried that same hash.
What the preview does not tell you: it is drawn smaller than your photo — 500 × 340 pixels for a 700 × 476 file, which is 51.0% of its pixels, and 453 × 340 for a 4,032 × 3,024 file, which is 1.26%. The size printed under it is rounded to the nearest kilobyte, so a 38,078-byte file is labelled 37 KB. And if you save the picture off the screen instead of pressing download, you get a re-compressed copy: re-encoding what was on screen produced 38,135 bytes instead of 38,078.
Everything below was measured today in Chrome 153 (headless, Windows, 1280 × 900, device pixel ratio 1) by driving the real page: handing it files, reading the bytes behind the preview, and reading the file that landed in the download folder.
The reason the two are identical is not a coincidence of timing — it is one assignment in the page's own code. This is the script as it is served today, read straight out of the live page:
var jpgUrl=URL.createObjectURL(jpgBlob);
prev.src=jpgUrl;
dlbtn.href=jpgUrl;
There is no second encode for the screen and no thumbnail step. The whole page calls createObjectURL once, and calls revokeObjectURL zero times — which is also why an older preview stays readable in memory after a new one replaces it, as noted at the end of this article.
For each conversion I made the page run normally, then compared three things: whether the preview's src and the download link's href were the same string, whether fetching those two URLs produced the same SHA-256, and whether the file that landed on disk had that same hash. All three held in every case.
| Input | Quality | JPG bytes | Same URL? | Preview hash = download hash? | File on disk |
|---|---|---|---|---|---|
| 41,465 B photo, 700 × 476 | 75% | 30,231 | yes | yes (45be985b347327e6…) | 30,231 B, same hash |
| 41,465 B photo, 700 × 476 | 85% | 38,078 | yes | yes (93859de257dc44a7…) | 38,078 B, same hash |
| 41,465 B photo, 700 × 476 | 95% | 57,617 | yes | yes (de678d5206fb5ce2…) | 57,617 B, same hash |
| 1,267,632 B photo, 4,032 × 3,024 | 85% | 1,708,595 | yes | yes (1fca374ec67e5fd5…) | 1,708,595 B, same hash |
| 41,465 B photo, 85%, three more runs | 85% | 38,078 | yes | yes, all three | 38,078 B each time |
The hashes shown are the first sixteen characters of the SHA-256. The repeats are worth stating separately: converting the same photo again and again produced one hash, 93859de257dc44a7…, in all four runs at 85% — which matches the figure recorded for this photo in the repeat-conversion measurements.
Same hash is strong, but it compares two fetches inside the browser. So I ran one more check that leaves the browser and comes back: after a conversion, I read the file out of the download folder, fed those exact bytes back into the page as a fresh blob, decoded it, and compared every channel value against what the on-screen preview had rendered.
Over 700 × 476 pixels — 1,332,800 channel values — the largest difference was 0, and the number of channels that differed at all was 0. The picture you are looking at is a faithful decode of the file you are about to save.
What the preview shows is the JPG, not your HEIC. The bytes behind it begin ff d8 ff e0 and end ff d9, while the photo I handed in begins 00 00 00 18 66 74 79 70 68 65 69 63 — the ftypheic marker. So the preview cannot tell you anything about what the conversion kept or dropped; for that, see the pixel-by-pixel quality measurements.
Three things you might read off the preview are not quite what they look like.
The image element is capped by the stylesheet at max-width:100% and max-height:340px, so both of my test files were drawn 340 pixels tall — 500 × 340 for the small one and 453 × 340 for the 12-megapixel one. That is 170,000 pixels drawn for a 333,200-pixel photo, and 154,020 drawn for a 12,192,768-pixel photo. A real screenshot of the preview area came out as a 500 × 340 PNG of 115,676 bytes. The aspect ratio is preserved in both cases, so nothing is stretched or cropped — but you are judging a full-resolution photo from a fraction of its pixels.
The line under the preview is built with (jpgBlob.size/1024).toFixed(0), which rounds to the nearest whole kilobyte and prints no unit beyond KB:
| Real output | What the page printed |
|---|---|
| 30,231 bytes | 30 KB |
| 38,078 bytes | 37 KB |
| 57,617 bytes | 56 KB |
| 1,708,595 bytes | 1669 KB |
Nothing is wrong with the file — the number is just rounded down to the nearest whole kilobyte in every one of these cases. The dimensions in that line are exact, taken from the decoded image.
This is the one that can quietly cost you quality. The bytes behind the preview are the finished JPG; the moment you capture what is on screen and re-encode it, you are compressing a second time. I drew the preview onto a canvas at its full pixel size and re-encoded it:
| The file you can download | Re-encoded from the screen at 85% | At 92% | As PNG |
|---|---|---|---|
| 38,078 bytes | 38,135 bytes (different hash) | 43,916 bytes | 268,499 bytes |
| 1,708,595 bytes | 1,708,558 bytes (different hash) | 1,954,798 bytes | 21,488,428 bytes |
Neither re-encode matched the original: at the same nominal 85% the small file came out 57 bytes larger and the big one 37 bytes smaller, and both had a different hash. The honest summary is that a screen capture starts a second JPEG generation, and if it is saved as PNG instead you get a file several times larger with no new detail in it.
Because both come from the same assignment, there is no window in which you can see the picture but not yet download it. Measuring from the moment the conversion finished, across the seven runs:
src and the download link's href were both set 1 to 2 milliseconds later — the same tick;So the download link is live from the instant the picture appears, and a slow conversion is slow before the preview shows up, not after.
An old preview stays in memory. Pressing Convert another hides the result area, but the image element keeps pointing at the old object URL — I could still fetch all 38,078 bytes of it afterwards. Converting a new photo replaces what is displayed, and the previous one was still readable at 38,078 bytes. That follows from the missing revokeObjectURL and is the same accumulation measured in the memory tests. You never see the stale picture, because its container is hidden.
A failed conversion leaves the previous result in the DOM. I handed the page a 2,231-byte file of JPEG bytes named .heic. It was rejected — the page showed its usual error, the result area stayed hidden, and the console logged HEIF image not found. Behind the scenes the preview element was untouched: its src was still the previous successful conversion, still loaded at 700 × 476, and the download link still pointed at that older JPG. Nothing on screen shows any of this, but it is the state the page is left in.
I did not test right-click saving, so I will not claim what your browser writes in that case. What I did measure is that the bytes behind the preview are the same bytes the download link serves, and that re-encoding what is on screen produces a different file. The download button is the path that gives you exactly those bytes.
Because it is drawn at 500 × 340 (or 453 × 340 for a 12-megapixel photo) — a capped height of 340 pixels. The file itself is full resolution; check the dimension in the line under the result, which is exact.
Yes, the preview is the file for whatever setting was selected when the photo was handed over: 30,231, 38,078 and 57,617 bytes for 75%, 85% and 95% on the same photo. Changing the setting afterwards does not re-encode the picture already on screen — measured in the mid-conversion quality tests.
The JPG. Its bytes start ff d8 ff e0 and end ff d9; the file I handed in started with the ftypheic marker. The preview is the output, not your original.
In my measurements, yes: the 12-megapixel file matched on all three checks too. I did not go beyond 1,267,632 bytes of input, so I will not extrapolate further.
I measured Windows and Chrome only. The identity comes from one line of the page's code, so I would expect the same result anywhere the page runs, but I did not measure other browsers or phone screen sizes and am not going to assert it.
Try it: open the converter, drop in a photo, and read the line under the result — then remember the file is a few hundred bytes larger than that number says.
First published: 6 October 2026