I put 200 twelve-megapixel HEIC files through this converter in one browser session, back to back: 9 minutes 30.6 seconds end to end, 2.77 seconds per file on average, 200 out of 200 succeeded. And you cannot do them in one go — the file input is single-select, so when I pushed five files in at once the browser kept one and converted that one. Batch here means two hundred single conversions in a row, not one conversion of two hundred.
Short answer: two hundred 12 MP HEIC files took 570.6 seconds of wall clock — 9 min 30.6 s — on this machine, in one Chrome tab that was never reloaded. The median file took 2,781 ms, the slowest 4,006 ms, the fastest 2,061 ms, and none of the 200 failed or produced a broken JPG. It did not slow down over the run: the last twenty files averaged 2,665 ms against 3,048 ms for the first twenty.
How I know: I generated 200 distinct 4032×3024 HEIC files, drove a real Chrome browser against this converter today, fed them in one at a time through the actual file input, and pulled every finished JPG back out of the browser to measure it. Every millisecond and every byte count below came out of that single run. Where I could not produce a number, I say so.
Before any timing matters, this decides what “batch” even means here. I checked it in the live page rather than guessing:
| What I checked | What the page said |
|---|---|
input.multiple on the file picker | false |
accept attribute | .heic,.heif,image/heic,image/heif |
| I pushed 5 files into the input at once | input.files.length came back 1 — Chrome kept the first |
| How many times the converter ran | once, producing batch_001.jpg |
The page’s own change handler reads files[0], and its drop handler reads dataTransfer.files[0] — so even if the browser handed over a whole folder, only the first file would be decoded. The drop-zone copy says “Drop your HEIC photo here”, singular, and that is literal.
The homepage also says “no batch limit”. Measured, that means there is no cap on how many conversions you run in a row — not that you can queue several at once. Two hundred in a row worked with no complaint, which is what the claim actually buys you.
| Measure | Result |
|---|---|
| Files attempted / succeeded / failed | 200 / 200 / 0 |
| Total wall clock | 570.6 s — 9 min 30.6 s |
| Time inside the converter (summed) | 554.6 s of that |
| Mean per file | 2,773 ms |
| Median per file | 2,781 ms |
| 90th percentile | 3,159 ms |
| Fastest / slowest single file | 2,061 ms / 4,006 ms |
| Total HEIC bytes in | 310,782,027 (296.4 MiB) |
| Total JPG bytes out | 376,611,979 (359.2 MiB) |
| Output ÷ input, whole run | 1.212× |
| Page reloads during the run | 0 — one tab, 200 conversions |
The spread per file: 10% of files finished under 2,381 ms, the middle half sat between 2,531 and 2,955 ms, and only the top 1% went past 3,971 ms. Nothing took longer than four seconds. The slowest file was batch_003 at 4,006 ms (a 1,680,340-byte HEIC); the fastest was batch_119 at 2,061 ms (1,011,815 bytes).
The 16.0-second gap between total wall clock (570.6 s) and summed conversion time (554.6 s) is my test harness — selecting each file and polling for the result, about 80 ms per file. It is not time the page spent.
This is the question that matters for a large batch, and the answer was no. Same tab, no reload, split into consecutive groups of twenty:
| Files | Mean conversion | Files | Mean conversion |
|---|---|---|---|
| 1–20 | 3,048 ms | 101–120 | 2,664 ms |
| 21–40 | 2,753 ms | 121–140 | 2,787 ms |
| 41–60 | 2,858 ms | 141–160 | 2,779 ms |
| 61–80 | 2,680 ms | 161–180 | 2,737 ms |
| 81–100 | 2,758 ms | 181–200 | 2,665 ms |
The last twenty files were 12.6% faster than the first twenty, not slower. The first group carries the cold start — the WebAssembly decoder is still being compiled and warmed on files 1–3 — and after that the run is flat for nearly ten minutes.
Memory behaved the same way. Measured after the first file, the JavaScript heap stood at 56.9 MiB; it then cycled between 10.9 MiB and 200.7 MiB as files were decoded and garbage collected, and stood at 57.0 MiB after the two hundredth. Two hundred 12 MP conversions in one tab left it holding nothing extra.
No. I ran the same twenty files three times over, once per setting:
| Setting | Mean per file | 20 JPGs, total bytes | Output ÷ input |
|---|---|---|---|
| 75% | 2,996 ms | 29,951,500 | 0.93× |
| 85% (default) | 3,034 ms | 39,204,528 | 1.22× |
| 95% | 3,010 ms | 65,635,997 | 2.04× |
The three means sit inside 38 ms of each other on identical input — about 1.3%, which is less than the run-to-run noise I measured on single files. But the bytes move enormously: the same twenty files produce 28.6 MiB of JPG at 75% and 62.6 MiB at 95%, a 2.2× difference in what lands on your disk for the same ten minutes of waiting.
So if your problem is time, lowering the quality setting does not help. If your problem is space, it is the only lever on the page. Individual files at 75% ranged 2,288–4,016 ms and at 95% 2,357–3,827 ms — the ranges overlap completely.
No. The file input is single-select — I pushed five files in and the browser kept one, converting only batch_001. You can convert 200 in a row without hitting any limit, but you do it one file at a time.
9 min 30.6 s in my run — 200 files at 4032×3024, 2.77 s each on average, at the default 85%. Your total will scale with your per-file time, so convert one photo first and multiply.
Mine did: 200 conversions in one tab with no reload, zero failures, and the JavaScript heap stood at 57.0 MiB after the 200th file against 56.9 MiB after the first. It also did not slow down — the last twenty files were faster than the first twenty.
No — it buys you nothing. 2,996 ms at 75% against 3,034 ms at 85% on the same twenty files. Drop to 75% for disk space, not for time: it produced 28.6 MiB where 95% produced 62.6 MiB.
I did not, across all 200. Reloading would only cost you the decoder download again — 678,928 bytes compressed (2,999,737 bytes uncompressed), 292 ms in my run.
After the first load, yes — the conversion makes no network requests, which is why it keeps working with the connection cut. See why it works with the network off.
Time your own batch: open the converter, convert one photo, read the seconds off your own watch and multiply — that is more honest than trusting my machine. Related: what a single conversion does to file size and what happens to colours.
First published: 25 September 2026