No. The same HEIC converted at device pixel ratio 0.5, 1, 1.5, 2 and 3 came out the same size, the same dimensions and the same hash every time.
Short answer: no. A Retina screen, a phone at 3×, or a desktop at 125% scaling does not make the converter write a bigger or smaller file. I converted the same 41,465-byte HEIC at devicePixelRatio 0.5, 1, 1.5, 2 and 3, on a desktop viewport and on a phone viewport: every run produced a 38,078-byte JPG at 700 × 476 pixels, hashing to the same SHA-256, 93859de257dc44a7…. I did the same with an 11,084,868-byte, 4,032 × 3,024 HEIC: all three runs produced 3,177,680 bytes at 4,032 × 3,024, hash 56ee525f012aa19f….
What does change: the preview on your screen. At device pixel ratio 1 the preview box is 500 × 340 device pixels; at 2 it is 1,000 × 680; at 3 it is 1,500 × 1,020 — all drawn from the same 700 × 476 image, so a high-DPI screen shows you a magnified preview of a file that did not grow.
How I measured it: today, against the live page, in Chrome 153.0.8010.54 (headless, Windows) driven through the DevTools protocol. Each of the ten runs got a fresh browser target with its own device metrics override, so device pixel ratio was set before the page ever loaded. Every run's full-page screenshot came back at the emulated size — 640 × 450 pixels at ratio 0.5 up to 3,840 × 2,700 at ratio 3 — which is how I know the emulation actually took effect.
Two source photos: the site's 41,465-byte sample and a 12-megapixel, 4,032 × 3,024 file. One conversion per run, each in a fresh target. Conversion is the time the converter's own function took; screenshot is the real pixel size of the full-page capture, which is the proof that the ratio was applied.
| Run | Viewport | Ratio | JPG bytes | Pixels | SHA-256 | Conversion | Screenshot |
|---|---|---|---|---|---|---|---|
| Desktop | 1280 × 900 | 1 | 38,078 | 700 × 476 | 93859de257dc… | 1,853 ms | 1280 × 900 |
| Desktop | 1280 × 900 | 1.5 | 38,078 | 700 × 476 | same | 1,016 ms | 1920 × 1350 |
| Desktop | 1280 × 900 | 2 | 38,078 | 700 × 476 | same | 985 ms | 2560 × 1800 |
| Desktop | 1280 × 900 | 3 | 38,078 | 700 × 476 | same | 837 ms | 3840 × 2700 |
| Desktop | 1280 × 900 | 0.5 | 38,078 | 700 × 476 | same | 1,572 ms | 640 × 450 |
| Phone | 390 × 844 | 3 | 38,078 | 700 × 476 | same | 1,306 ms | 1170 × 2532 |
| Phone | 390 × 844 | 2 | 38,078 | 700 × 476 | same | 1,977 ms | 780 × 1688 |
| Desktop, 12 MP | 1280 × 900 | 1 | 3,177,680 | 4032 × 3024 | 56ee525f012a… | 14,931 ms | 1280 × 900 |
| Desktop, 12 MP | 1280 × 900 | 3 | 3,177,680 | 4032 × 3024 | same | 6,990 ms | 3840 × 2700 |
| Phone, 12 MP | 390 × 844 | 3 | 3,177,680 | 4032 × 3024 | same | 8,104 ms | 1170 × 2532 |
The layout did not move either: the upload zone sat 288 px from the top of the page in all five desktop runs and 333 px in both phone runs, and the preview box measured 500 × 340 CSS pixels on desktop and 316 × 215 on the phone viewport regardless of ratio. Ratio changes how many physical dots each CSS pixel is painted with; it does not change the CSS layout or the file.
Conversion times above look uneven — 837 ms at ratio 3 and 1,853 ms at ratio 1 — which could be mistaken for a ratio effect. It is not: each run used a fresh page, so the first run also paid for the decoder arriving and warming up. To take that out, I ran a second sequence in one single page, switching the ratio between conversions:
| Order | Ratio at that moment | JPG bytes | Pixels | Conversion |
|---|---|---|---|---|
| 1st | 1 | 38,078 | 700 × 476 | 1,236 ms |
| 2nd | 3 | 38,078 | 700 × 476 | 684 ms |
| 3rd | 0.5 | 38,078 | 700 × 476 | 190 ms |
| 4th | 2 | 38,078 | 700 × 476 | 131 ms |
| 5th | 1 | 38,078 | 700 × 476 | 132 ms |
| 6th (12 MP) | 1 | 3,177,680 | 4032 × 3024 | 10,158 ms |
| 7th (12 MP) | 3 | 3,177,680 | 4032 × 3024 | 6,694 ms |
| 8th (12 MP) | 1 | 3,177,680 | 4032 × 3024 | 5,151 ms |
Eight conversions in one page, two distinct outputs, and the times fall as the page warms up — not as the ratio changes. The slowest run is at ratio 1 and the fastest is also at ratio 1.
A converter can only be affected by device pixel ratio if it reads it. This one does not. The homepage HTML I fetched today is 13,927 bytes and the string devicePixelRatio does not appear in it once. The decoder it loads, heic-to.js, is 2,999,737 bytes uncompressed and also contains 0 occurrences of devicePixelRatio.
The mechanism matches: in every one of the ten runs the page created exactly one canvas element, and it was 1 × 1 pixels at the end; no canvas was ever attached to the document; and each run started 1 web worker. The pixel work is not going through a canvas in the page that a browser would scale up for a sharp screen.
That is the ordinary behaviour of a canvas, and worth stating plainly: a canvas has its own pixel size, separate from the CSS box it is drawn into. A converter that wanted a high-DPI output would have to set the canvas to pixels × ratio on purpose. Nothing here does, so the output resolution comes from the photo and nothing else.
Not your screen. On this converter the things that move the number are the photo itself and the quality setting, both measured on this site before: the same 700 × 476 sample at quality 75 came out 30,231 bytes, at 85 38,078 bytes, and at 95 57,617 bytes. A 4,032 × 3,024 photo at quality 85 came out 3,177,680 bytes — the same figure I got today at three different ratios. If your JPG is a different size than someone else's, the cause is the source photo or the slider, not the display.
That is what the measurements say: identical bytes and identical dimensions at ratios 1, 2 and 3. I set the ratio through the browser's own device-metrics emulation rather than by plugging in different physical displays, so what I tested is the value the page sees — which is the only thing it could react to.
I did not test those exact steps, and I will not claim a number for them. What they do is set the same devicePixelRatio value to 1.25 or 1.5 — and 1.5 is one of the ratios I did test, where the output was the usual 38,078 bytes.
It is being stretched. The preview box is 500 × 340 CSS pixels, which at ratio 3 is 1,500 × 1,020 device pixels, filled from a 700 × 476 image. That is the browser upscaling what it displays, not a change to the file — the download is still 700 × 476.
No. Both phone-viewport runs produced the same 38,078-byte JPG as the desktop runs, and the 12-megapixel photo came out at 3,177,680 bytes on the phone viewport too. The page does not look at the viewport to decide output size.
Not from this converter, and not by changing your display. The output was 700 × 476 for the 700 × 476 source and 4,032 × 3,024 for the 4,032 × 3,024 source in all ten runs. The file-size measurements cover what does move the number.
I measured device pixel ratio, which is what a screen's density sets, and I did not measure browser zoom separately — so I am not putting a number on zoom. Zoom changes the CSS pixel size of things on screen, in the same family as the layout differences I did record: 500 × 340 on desktop versus 316 × 215 on a phone viewport.
Across days, on this site: the 4,032 × 3,024 photo hashed to 56ee525f012aa19f… today and the same hash has been recorded for it on other days, including in the repeat-conversion measurements. Today's question was narrower — whether the ratio changes it, and it does not.
Try it: open the converter on a laptop and then on a phone, convert the same photo, and compare the two file sizes — they should match to the byte.
First published: 7 October 2026