It depends on the photo, and for a modern phone photo it is optimistic. A 12-megapixel image took 3,918 ms at the median across 20 runs today — about twice the claim. Two seconds is the right number for a 3-megapixel image.
Short answer: the claim is not a lie, but it is not the number you will see for a full-resolution phone photo. Measured today on this site: a 12-megapixel image (4032 × 3024) took 3,918 ms at the median over 20 consecutive runs, with a range of 3,604 to 4,934 ms. A 3-megapixel image (2048 × 1536) took 1,762 ms — that is the size "about 2 seconds" describes. Below that it is much faster, above it much slower.
What I measured today (15 October 2026): 97 conversions on the live site across nine files from 41,465 bytes to 24,470,938 bytes, five runs per size plus two 20-photo batches, on Chrome 155.0.8059.40. Every number below came out of those runs.
Before measuring it I went looking for it. On today's homepage there are zero occurrences of the word "second" — the badges read "No upload", "No signup", "No watermark". The figure lives in one place: the hero badge of the offline conversion page, which reads ≈2 s per photo. The same page also says a file converted "in roughly two seconds".
So this is a claim this site makes about itself. Here is the measurement that checks it.
Each file was converted five times in a row on the live page, and I took the median. The page's own size line is included so you can see what it reported back:
| Image | Source file | JPG out | Median | Range |
|---|---|---|---|---|
| 700 × 476 (real photo) | 41,465 B | 38,078 B | 352 ms | 234 – 1,715 ms |
| 1024 × 768 | 737,078 B | 210,716 B | 574 ms | 435 – 1,275 ms |
| 1600 × 1200 | 1,777,282 B | 509,794 B | 1,076 ms | 737 – 1,687 ms |
| 2000 × 1500 | 2,768,977 B | 795,543 B | 1,598 ms | 1,149 – 2,597 ms |
| 2048 × 1536 | 2,894,431 B | 832,090 B | 1,762 ms | 1,023 – 4,426 ms |
| 4032 × 3024 (photo content) | 2,489,467 B | 410,116 B | 2,014 ms | 1,925 – 2,083 ms |
| 4032 × 3024 (synthetic) | 11,084,868 B | 3,177,680 B | 5,178 ms | 4,371 – 5,757 ms |
| 3024 × 4032 (portrait) | 11,092,831 B | 3,183,635 B | 4,185 ms | 3,871 – 5,162 ms |
| 6000 × 4500 | 24,470,938 B | 7,013,308 B | 9,453 ms | 8,997 – 11,767 ms |
Read down the median column and the shape is clear: a third of a megapixel is a third of a second, three megapixels is under two seconds, twelve megapixels is four to five seconds, and twenty-seven megapixels is nine and a half.
The five-run ladder above includes each file's first run, which is always the slowest. To get a steady-state number I converted the same 12-megapixel file twenty times back to back:
| Measure | Value |
|---|---|
| Median conversion | 3,918 ms |
| Mean conversion | 3,988 ms |
| Fastest | 3,604 ms |
| Slowest | 4,934 ms |
| 90th percentile | 4,683 ms |
| Total wall clock for all 20 | 81,459 ms |
| Time actually spent converting | 79,750 ms |
It does not slow down over the run: the slowest conversion in the batch was not the last one, and the spread from fastest to slowest is 1,330 ms across twenty photos. Twenty 12-megapixel photos cost about 81 seconds end to end.
The same exercise with the 41,465-byte photo: total wall clock 3,146 ms for twenty conversions, median 122 ms, mean 117 ms, fastest 67 ms, slowest 205 ms. Every one of them produced the same 38,078-byte file. At that size "about 2 seconds" is pessimistic by a factor of sixteen.
Look at rows six and seven of the ladder. Both files are 4032 × 3024 — identical pixel counts. One took 2,014 ms and the other took 5,178 ms.
The faster one is a real photograph resized to 12 megapixels and stored at 2,489,467 bytes. The slower one is generated content — gradient, stripes and per-pixel noise — stored at 11,084,868 bytes, about 4.5 times more data for the same number of pixels. Decoding it costs about 2.6 times as long.
I want to be exact about what this does and does not prove: I did not separate "more bytes to decode" from "harder content to decode", because those two moved together in my samples. What I can say from the measurement is that resolution alone does not tell you the time — the file's own weight matters too. So a 12-megapixel HEIC can land near two seconds or near five, depending on what is inside it.
No. Three runs each at the three settings on the same 12-megapixel file:
| Quality | Mean conversion | JPG out |
|---|---|---|
| 75% | 3,907 ms | 1,938,206 B |
| 85% (default) | 3,853 ms | 3,177,680 B |
| 95% | 4,082 ms | 6,115,723 B |
The output triples in size from the lowest setting to the highest while the time moves by about 6%. Picking the higher quality costs you disk space, not waiting time.
Opening a brand new tab and converting the small photo three times gave 1,418 ms, then 162 ms, then 144 ms. The same pattern showed up at every size in the ladder — the first run of each file was the slowest, sometimes several times slower than the rest.
If you convert one photo, that first-run penalty is the whole experience. If you convert twenty, it is a rounding error. I did not investigate what causes it, so I am not going to name a cause.
Here is the fair reading of today's numbers:
There is also time before any of this: the page itself was ready in 1,141 ms on today's run, which is the decoder arriving before you can convert anything.
Because the decoding and re-encoding happen on your own device, so the time is your machine's time, not a server's. That is the trade: nothing leaves your computer, and in exchange the work is done by your CPU. A faster machine will beat every number on this page; a slower one will be slower still — I measured that separately on Converting on a slow device, where a loaded CPU made every conversion several times longer without changing the output.
No, and doing it the wrong way is slower. Dropping a second file in while one is still converting makes both of them compete for the same CPU — I measured that in Dropping a second photo in mid-conversion. Converting in sequence is what the timings on this page describe.
Yes, noticeably. In a fresh tab the first small photo took 1,418 ms and the next two took 162 ms and 144 ms. The twenty-photo batches on this page are steady-state numbers and do not include that first-run penalty.
Yes. All twenty small-photo conversions produced the same 38,078-byte file, and I have checked byte-for-byte repeatability across many runs and two browsers in Converting the same HEIC ten times.
Not directly. Every figure here is from desktop Chrome 155.0.8059.40 on this machine. A phone CPU will be slower, and I have not measured on-device times on a phone, so I will not convert these numbers into phone estimates.
They work, they just take longer — 24,470,938 bytes at 6000 × 4500 took 9,453 ms at the median. I pushed file sizes well past that to find where it breaks in How large a HEIC can this converter take, and it did not break.
The honest way to read any speed claim on a converter, including this one, is as an order of magnitude rather than a promise: small photos are instant, mid-sized photos are a couple of seconds, full-resolution photos are a few seconds.
Try it: open the converter and time one of your own HEIC files against the table above.
First published: 15 October 2026