On this converter a 12 MP HEIC of 1,246,105 bytes became a JPG of 1,890,014 bytes at the default 85% — 1.52× bigger, in 3.5 to 4.6 seconds. The famous “HEIC is half the size” did not survive contact with a real photograph: at 75% that photo’s JPG came out smaller than the HEIC it was made from.
Short answer: converting a HEIC to JPG on this page makes the file bigger by about half at the default 85% setting — 1.19 MB in, 1.80 MB out for a 12 MP image — and takes roughly three and a half to four and a half seconds per photo at that size. Dropping to 75% removes 24% of the bytes; going to 95% adds 68%. And the size ratio is not a constant: across three 4032×3024 files with identical pixel counts I measured 5.50×, 1.52× and 0.77×, purely because of what was in the picture.
How I know: I drove a real Chrome browser against this converter today, one file at a time, at each of the three quality settings the page offers, and pulled the finished JPG back out of the browser to measure it on disk. Every byte count and every millisecond below came out of that run. Where I could not produce a number, I say so.
| File | Pixels | What is in it | HEIC bytes |
|---|---|---|---|
real_700.heic | 700×476 | Real photograph shipped with this project (no camera EXIF in it) | 41,465 |
photo_1920.heic | 1920×1440 | Synthetic, photo-like detail: smooth gradient plus soft structure and light grain | 282,066 |
photo_4032.heic | 4032×3024 | Same recipe as above at 12 MP | 1,246,105 |
flat_4032.heic | 4032×3024 | Synthetic, smooth gradient with almost no detail | 18,327 |
noisy_4032.heic | 4032×3024 | Synthetic, the same scene buried under heavy grain | 5,500,728 |
Four of these five I generated myself with Pillow and pillow-heif, encoded at HEIC quality 60. Only real_700.heic is an actual photograph, and it carries no camera EXIF, so I cannot tell you what shot it. I did not have a camera-original iPhone HEIC on this machine, so I am not claiming a number for one. Treat the synthetic rows as controlled comparisons, not as typical phone output.
| Source | HEIC | JPG at 75% | JPG at 85% | JPG at 95% |
|---|---|---|---|---|
| 700×476 real photo | 41,465 | 30,231 (0.73×) | 38,078 (0.92×) | 57,617 (1.39×) |
| 1920×1440 photo-like | 282,066 | 326,701 (1.16×) | 427,238 (1.51×) | 718,714 (2.55×) |
| 4032×3024 photo-like | 1,246,105 | 1,445,569 (1.16×) | 1,890,014 (1.52×) | 3,177,770 (2.55×) |
Two things fall out of that. First, the resolution barely matters to the ratio: 1920×1440 and 4032×3024 produce 1.16× / 1.51× / 2.55× and 1.16× / 1.52× / 2.55× — the same multipliers at nine times the pixel count. Second, the quality setting is the biggest lever on this page: on the 12 MP file, 75% costs 445,445 bytes less than 85%, and 95% costs 1,287,756 bytes more.
I also ran the 12 MP file at 85% three separate times. It produced 1,890,014 bytes every time — the byte counts above are not averages of noisy results, they are reproducible.
The size the page shows you is the real byte count rounded to KB: 1,890,014 bytes is displayed as “1846 KB”. It is not an estimate.
Three files, same 4032×3024, same 85% setting, same converter. Only the content differs:
| Content | HEIC bytes | JPG bytes at 85% | JPG ÷ HEIC |
|---|---|---|---|
| Smooth gradient, almost no detail | 18,327 | 100,826 | 5.50× |
| Photo-like detail | 1,246,105 | 1,890,014 | 1.52× |
| Same scene under heavy grain | 5,500,728 | 4,209,166 | 0.77× |
The spread runs from 5.5× bigger to 23% smaller, at identical pixel counts. HEIC is very good at holding detail cheaply and JPG is not, so a picture that is mostly flat sky turns into a JPG five times the size, while a picture that is mostly noise ends up smaller than the HEIC that produced it. This is why “HEIC is about half the size of JPG” cannot be turned into a prediction for your file — it is a statement about two encoders aimed at the same visual quality, not about one file converted into another.
I did not measure perceptual quality — no SSIM, no PSNR, no side-by-side panel — so I will not claim that the 85% JPG looks as good as the HEIC it came from. I only measured bytes and seconds.
| File | Setting | Convert time | Drop to downloadable |
|---|---|---|---|
| 700×476 real photo | 85% | 589 ms | 808 ms |
| 1920×1440 photo-like | 85% | 1,302 ms | 1,389 ms |
| 4032×3024 photo-like | 75% | 4,445 ms | 4,745 ms |
| 4032×3024 photo-like | 85% | 3,545 / 4,573 / 3,527 ms | 3,859 / 4,779 / 3,922 ms |
| 4032×3024 photo-like | 95% | 3,592 ms | 4,147 ms |
| 4032×3024 flat gradient | 85% | 1,781 ms | 1,874 ms |
| 4032×3024 heavy grain | 85% | 5,995 ms | 6,657 ms |
The quality setting barely moves the clock: the same 12 MP file took 4,445 ms at 75% and 3,592 ms at 95%, and the three runs at 85% spread from 3,527 to 4,573 ms on their own. Run-to-run variation on this machine is larger than the effect of the quality dial. What does move it is pixel count and detail: 0.6 s at 0.33 MP, 1.3 s at 2.8 MP, 3.5–4.6 s at 12 MP, and 6.0 s for the 12 MP file that was mostly noise.
The second column is what you actually wait for — from dropping the file to the download link being ready. It runs about 100 to 300 ms above the conversion itself.
Converting a second file in a page that is already warm is faster: in one session the 1920×1440 file took 1,397 ms as the first conversion, the 12 MP file took 2,934 ms as the second, and the 700×476 file took 167 ms as the third. Same code, same machine, shorter clock.
These are headless Chrome runs on one Windows machine through a local proxy. Your numbers will differ — the ratios should hold better than the milliseconds. The only network cost is the first load: the decoder arrives as 678,928 bytes compressed (2,999,737 bytes uncompressed) and took 658 ms to fetch in my run. After that the conversion makes no network requests, which is why it still works with the connection off.
No. All seven conversions kept their input dimensions exactly — 700×476, 1920×1440 and 4032×3024 came out unchanged. Only the encoding changes.
It cost 68% more bytes than 85% on my 12 MP file. I did not measure the visual difference, so I cannot tell you whether you would see it — only what it costs in bytes.
Because the ratio depends on the picture, not the format. In my run the real photograph at 75% produced 30,231 bytes from a 41,465-byte HEIC, and the grain-heavy 12 MP file produced 4,209,166 bytes from 5,500,728. Both ended up smaller than their source.
I have not measured batch conversion — every number on this page is one file at a time. I will not multiply a single-file number by 200 and call it a measurement.
Not after the first load. The decoder download is 678,928 bytes compressed and is cached by the browser; from then on the work happens on your device with no network involved, which is why the page keeps working with the connection cut.
Yes, in my testing. Three separate runs of the 12 MP file at 85% all produced 1,890,014 bytes.
Measure your own: open the converter, drop one photo in, and read the size off the result line — it is the real byte count of the file you are about to download. Related: what happens to colours and why it works with the network off.
First published: 24 September 2026