Reload, navigate away or close the tab and the conversion is gone — no resume, no warning. Switch to another tab and it finishes anyway.
Short answer: if you reload the page, navigate to another URL, or close the tab while a conversion is running, the conversion is thrown away completely. There is no resume and no partial credit: you come back to an empty converter, and the file has to be converted again from the beginning, at full cost. Switching to another tab is the exception — the conversion keeps going and finished normally in every test I ran.
What I measured today, on this site in Chrome 153: I interrupted a 12-megapixel conversion (11,084,868 bytes in, 3,177,680 bytes out) part-way through and then redid it: interrupting after 2,831 ms and starting over cost 5,803, 6,524 and 8,930 ms, against 4,132–7,461 ms for an uninterrupted run of the same file. The work already done is simply discarded. Nothing is left behind: no error message, no console entry, no partially written file — and the finished JPG, when it does come out, is byte-identical to the one an uninterrupted run produces.
There is also no warning of any kind. The page has no beforeunload handler, and navigating away mid-conversion produced 0 dialogs.
A conversion here is not a job on a server that survives a reload. It is a promise inside one JavaScript document: the file is handed to a decoder running in your own browser (nothing is uploaded — see the network-layer proof), and the finished JPG is held in memory as a blob URL. When the document is replaced, that promise, the blob and the file name all die with it.
I checked every place a page could have stashed something to come back to:
| Where state could hide | What I found |
|---|---|
localStorage | 0 keys, before and after a conversion |
sessionStorage | 0 keys, before and after a conversion |
| IndexedDB | 0 databases |
| Cache API | 0 cache keys |
window.onbeforeunload | null — no leave-prompt is even possible |
So the answer to "can it pick up where it left off" is not "not yet" — there is nothing to pick up from.
I started a 12-megapixel conversion and hit reload at three different points, then converted the same file again. Each run was on a freshly loaded page:
| Reloaded after | What the page was doing | What I came back to | Ready again | Rerun cost | Output |
|---|---|---|---|---|---|
| 1,509 ms | converting — spinner visible | empty converter | 306 ms | 8,431 ms | 3,177,680 bytes |
| 5,032 ms | converting — spinner visible | empty converter | 282 ms | 7,087 ms | 3,177,680 bytes |
| 8,554 ms | already finished — result on screen, download address live | empty converter | 232 ms | 5,337 ms | 3,177,680 bytes |
Two things are worth reading off that table. First, you do not come back to a stuck spinner or a complaint. In the first two runs the spinner block was visible when I hit reload; in all three I came back to the page's clean starting state — spinner hidden, result hidden, error hidden, file input empty, quality menu back at 0.85. The interruption leaves no trace at all.
The third row is worth a second look, because it was not an interruption at all: by 8,554 ms that run had already finished, the result block was showing and the blob address was live. So that reload destroyed a completed JPG rather than a conversion in flight — and the redo still cost 5,337 ms. There is no discount for progress made, and no discount for having finished either.
The reload itself is not held up by the conversion. From issuing the reload to the converter being ready again took 100–306 ms across every interrupted reload today, against 116–119 ms for reloading the same page while idle. The browser does not wait for the in-flight conversion to finish before letting go of the page — it simply drops it.
The expensive part is the rerun, and the timing says the interrupted work is fully wasted. Against a warm baseline of 4,132–7,461 ms for this file (six runs on one page: 7,890, 7,461, 5,733, 5,327, 4,132 and 5,650 ms), the three reruns after interrupting at 2,831 ms took 8,930, 5,803 and 6,524 ms.
No. I interrupted the same conversion three times in a row (each time after 1,698 ms, reloading between them) and then let one run finish. It completed in 7,120 ms, produced 3,177,680 bytes, and that output was byte-identical to the baseline — same SHA-256 as a run that was never interrupted. The error box was empty, the spinner was hidden, and the result block was displayed normally. During the interrupted runs the browser logged 0 error or console entries: from the page's point of view, nothing went wrong, because the page was simply gone.
Same outcome, two more routes:
undefined and the upload area was not in the document at all. Coming back took 141 ms to be ready, and the decoder cost 0 bytes over the network on that return trip (its 678,928 bytes came from cache), so returning is cheap. The state was empty; redoing the conversion took 8,369 ms.The one thing that is not lost by leaving is something you already have. If the conversion had finished and you had already pressed download, leaving immediately does not take the file with it: I clicked download and navigated away in the same breath, and the file still landed on disk complete — 38,078 bytes, exactly the same as the control download I let finish normally.
Refreshing after a successful conversion, before you download, loses the JPG too — the finished file only ever existed in memory. I converted a 700×476 photo (38,078 bytes out), read the download link's blob address back and fetched it successfully, then reloaded. Afterwards:
Failed to fetch — the file it pointed at no longer exists.For that small photo the redo is cheap — 201 and 346 ms in today's warm runs — so it is a nuisance rather than a disaster. It scales with the file: the same mistake on the 12-megapixel file costs thousands of milliseconds, and on a batch of 200 files it costs the whole queue.
This is the good news, and it is the case most people actually mean by "switching away". I opened a second tab and brought it to the front, confirmed the converter's tab reported visibilityState of hidden, started a conversion there, and left it in the background. All three background runs finished, and all three produced 3,177,680 bytes with the same SHA-256 as the foreground runs:
| Run | Tab visibility | Conversion time | Output |
|---|---|---|---|
| 1 | hidden | 7,314 ms | 3,177,680 bytes |
| 2 | visible (foreground control) | 5,542 ms | 3,177,680 bytes |
| 3 | hidden | 9,490 ms | 3,177,680 bytes |
| 4 | visible (foreground control) | 5,183 ms | 3,177,680 bytes |
| 5 | hidden | 6,825 ms | 3,177,680 bytes |
| 6 | visible (foreground control) | 5,535 ms | 3,177,680 bytes |
Background runs were slower in every pair — 6,825–9,490 ms against 5,183–5,542 ms in front — so leaving a tab is not free, but nothing is lost and nothing has to be redone. The decoding happens off the main thread, which is presumably why it runs on at all; I did not measure which thread does what today.
I also tested the harsher version: browsers freeze tabs you have not looked at for a while. I put a counter on the page ticking every 100 ms, started a conversion, and froze the tab for 10 seconds. The counter stuck at 8 for all 20 samples I took during the freeze and moved again afterwards, so the page really was suspended. The conversion then took 17,953 ms end to end against 5,721 ms for an unfrozen control — it did not progress while frozen, but it resumed and finished with identical output when the tab was active again. A frozen tab costs you wall-clock time, not the conversion.
One thing I could not measure: minimising the window or switching to a different application. I can drive tabs, not the window manager, so I have no number for that and I am not going to invent one.
No. It has no beforeunload handler at all, and navigating away mid-conversion produced 0 dialogs. There is no prompt to dismiss and no confirmation to click through — which also means there is nothing to stop you.
Yes. All three background runs completed and produced byte-identical output to the foreground runs. They were slower — 6,825–9,490 ms against 5,183–5,542 ms — so expect to wait longer, but expect a result.
No. The work lives inside that document. A new tab starts empty, and the conversion has to run again from the start.
No. I found 0 localStorage keys, 0 sessionStorage keys, 0 IndexedDB databases and 0 cache keys, both before and after a conversion.
No. On a return visit the decoder's 678,928 bytes came from cache with a transfer size of 0; the page was ready again in 141 ms. I tried to catch the very first load mid-download by reloading 500 ms after navigating, but the decoder was already present by then, so I have no measurement of a reload during the decoder's own download.
Nothing I could find: no error message, no console entry, no partial download. Every completed conversion I measured, interrupted or not, produced the same 3,177,680 bytes for that file.
Try it: open the converter, drop a photo in, and switch to another tab while it works — then try reloading instead.
First published: 5 October 2026