Nothing queues and nothing warns you. Both photos decode at once, both get slower, and the last one to finish owns the result area — under the name of whichever file was dropped last.
Short answer: the page starts a second conversion immediately — there is no queue, no "busy" lock and no warning. The two run at the same time, and both pay for it: in today's tests a 700 × 476 photo that takes 217 ms on its own took 4,732 ms while a 12-megapixel decode was running beside it. Whichever conversion finishes last writes its result to the screen, so the photo you end up with is the last one to complete, not the last one you dropped.
What I measured today, on this site in Chrome 153: two 12-megapixel files dropped 200 ms apart finished 6,677 ms and 10,971 ms after they started — their windows overlap, which is the proof they run concurrently — against 8,583 ms for one of them alone. Three files at once took 5,912, 5,866 and 10,116 ms. Nothing failed and nothing was cancelled; both files always produced their usual output (3,177,680 bytes for the 12-megapixel one, 38,078 bytes for the small one).
The part that can actually bite you is the name. The file name is stored in one shared place that every new file overwrites, so a result can come out labelled — and downloaded — with the other photo's name.
The file picker on this page is a single <input type="file"> with multiple set to false — but that flag only governs selecting several files in one dialog. Nothing prevents a second, separate selection while a conversion is running:
disabled as false while a conversion was in flight.accept list is .heic,.heif,image/heic,image/heif; it is hidden from the page (hidden, computed display: none) and it is the only <input> on the page.So the second file simply starts the whole routine again: spinner on, result hidden, error hidden, decode started.
| What I dropped | Each conversion took | Whole batch took |
|---|---|---|
| One 12-megapixel file (11,084,868 bytes) | 8,583 ms | — |
| One 700 × 476 photo (41,465 bytes) | 217 ms | — |
| Two 12-megapixel files, 200 ms apart | 6,677 ms and 10,971 ms | 11,243 ms |
| Three files (12 MP, small, 12 MP) at 0 / 300 / 600 ms | 5,912 ms, 5,866 ms and 10,116 ms | 11,284 ms |
The overlap is the tell: with two files 200 ms apart, the second one finished at 11,796 ms of page time while the first had finished at 7,278 ms — they were in flight together for most of that. If the page queued them, the second would have started where the first ended.
The cost is not shared politely. The small 700 × 476 photo needs 217 ms alone; in the three-file run it took 5,866 ms, and in the big-then-small run 4,732 ms — roughly twenty times its solo time, purely because two 12-megapixel decodes were occupying the machine. Dropping a second file does not make your first photo finish sooner; it makes both finish later.
I started a 12-megapixel file, waited 1,000 ms, then dropped a small photo. The big one finished first, in 5,584 ms; the small one, which had started a second later, took 4,732 ms and finished last. Here is what the page looked like, sampled every 400 ms:
| Time | Spinner | Result block | Info line |
|---|---|---|---|
| 4,000 ms | visible | hidden | (empty) |
| 4,400 ms | gone | shown | n2.jpg — 4032×3024 — 3103 KB |
| 4,800 ms | gone | shown | n2.jpg — 700×476 — 37 KB |
Two things to notice. The spinner went off at 4,400 ms when the first conversion finished, even though the second was still running — so a still spinner is not the only signal, and a stopped spinner does not mean everything is done. And the final line is the small photo, because it was the last to finish. Run it the other way round — small first, 12-megapixel second — and the screen ends on m5.jpg — 4032×3024 — 3103 KB, the big one, again because it finished last.
Look again at the 4,400 ms row: the size and dimensions on that line (3103 KB, 4032×3024) belong to the 12-megapixel photo, but the name n2.jpg belongs to the small photo that arrived second. The page keeps one shared variable for the file name and every new file overwrites it, so whichever conversion finishes afterwards picks up the newest name, not its own.
It gets worse with a file that fails. I started a 12-megapixel conversion and then dropped a file that contains real JPEG bytes under a .heic name (2,231 bytes). The bad file failed after 3,942 ms, and then the good one finished. What I ended up with:
bad1.jpg — 4032×3024 — 3103 KB, and the download link's filename was bad1.jpg. That is a perfectly good 3-megapixel-class JPG of the real photo, offered under the name of the file that failed.If you download at that moment you get the right picture under the wrong name. The decoder's own complaint, by the way, only appears in the browser console: HEIF image not found — the page shows every failure as the same sentence.
When a second conversion finishes, it overwrites the download link, but it does not destroy what was there. In a two-small-photo run I kept the first result's blob address, let the second conversion replace the link, and then fetched the old address again: it still returned 38,078 bytes, the same file. The page never revokes these, so finished conversions stay in memory for as long as the tab lives. Heap readings either side of that run were 73,312,922 and 72,422,588 bytes, so in this small case nothing accumulated — I did not measure memory across a long session.
I also triggered the page's own drop handler directly, dispatching a real drag event carrying a 41,465-byte HEIC file. It converted normally — 38,078 bytes in 659 ms, shown as dragged.jpg — 700×476 — 37 KB — so both entry points into the page run exactly the same routine. To be precise about what that proves: the event was constructed in the browser, not dragged in from the desktop by an operating-system drag, so I have tested the page's handler, not the operating system's file drag.
No. Both ran to completion in every test — two files, three files, and a good file alongside a broken one. I never saw a conversion abandoned.
Not in size. The 12-megapixel file came out at 3,177,680 bytes and the 700 × 476 photo at 38,078 bytes whether they ran alone or alongside others — the same figures as in the repeat-conversion measurements. Only the time changes.
Because the two conversions share the machine rather than taking turns politely. I measured the effect (217 ms alone, 4,732–5,866 ms under contention) but I did not investigate which resource they contend for, so I will not name one.
The result area gets overwritten by whichever conversion finishes last, and the old result stays fetchable in memory, so nothing is destroyed — but if you walk away mid-way you can come back to a different photo than you expected. Reloading is what really throws work away; that is covered in the reload and tab-switch measurements.
Not on this page as measured: the file input has multiple set to false, so one dialog gives you one file. Converting many photos means repeating the step, which is what the 200-file timing run measured.
Try it: open the converter, drop one photo, then drop a second while the spinner is still turning and watch which name lands on the result.
First published: 5 October 2026