No. Not while your photo is still converting, not when the finished JPG is sitting there undownloaded, and not when you close the tab. I left the live page five different ways and the browser raised zero prompts every time.
Short answer: no. Nothing asks you to stay. I drove the real page today and left it in five different states — idle, mid-conversion, with a finished JPG on screen, right after pressing download, and after clearing the result — and the browser raised 0 dialogs in every one. The reason is not subtle: the page registers no beforeunload handler. The HTML as it is served today is 13,949 bytes, and the word beforeunload appears 0 times in it.
What leaving costs you: in one tab I converted three photos — two small ones and a 12-megapixel one — and then closed the tab. 3,253,836 bytes of finished JPG, the product of 6,527 ms of decoding on this machine, were gone. A fresh tab was ready 236 ms later with an empty result area, an empty info line and an empty download link. Nothing came back.
The one thing that does survive: pressing Download JPG first. A 3,177,680-byte file landed complete on disk even when I navigated away in the same instant, and even when I closed the tab in the same instant. Once the download has been handed to the browser, the page is no longer part of it.
Everything below was measured today on the live page in Chrome 153.0.8010.54 (headless, Windows, window 1280 × 900), by handing it real files and counting every dialog the browser raised through the DevTools protocol.
For each row I opened a fresh tab, clicked once on the page so that it counted as "used", put it into the state described, and then navigated to another page on the same site. The click matters: Chrome only shows a leave-prompt at all once you have interacted with the page, which is why every row includes one.
| Moment I left | What was on screen or in memory | Browser dialogs | Where it ended up |
|---|---|---|---|
| Page just loaded, nothing converted | empty converter | 0 | the other page, no interruption |
| Mid-conversion, 12-megapixel photo | spinner showing Converting… | 0 | the other page, conversion abandoned |
| Result on screen, not downloaded | 38,078 B JPG, s2.jpg — 700×476 — 37 KB | 0 | the other page |
| Right after pressing Download | 38,078 B already on disk | 0 | the other page; file still 38,078 B |
| After Convert another | result area hidden, old JPG still behind the link | 0 | the other page |
In the third row I came back afterwards to see what a returning visitor would find: the result area was hidden, the info line was empty, and the download link had no href of its own — it pointed back at the page URL. The JPG was still technically in the browser's memory, but there was nothing on screen to click. Closing the tab behaved the same way: mid-conversion with the spinner running, 0 dialogs; with a finished 38,078-byte JPG waiting, 0 dialogs.
A browser only puts a "Leave site?" box in front of you if the page has registered a handler for the beforeunload event. This one has not, and it is easy to check on the page as it is served right now:
| Token | Times it appears in the live HTML |
|---|---|
beforeunload | 0 |
unload | 0 |
pagehide | 0 |
visibilitychange | 0 |
confirm( / alert( | 0 / 0 |
Reading it back at runtime tells the same story: window.onbeforeunload was null before a conversion and still null immediately after one. I also recorded every listener the page added to window while it loaded — 27 of them, four visibilitychange, eight pageshow, three pagehide, three load, and one each of click, keydown, hashchange, popstate, focus, blur, resize, scrollend and prerenderingchange. Not one of them was beforeunload or unload, and none of the others can stop a navigation.
The page does not warn you in words either. Its visible text runs to 4,120 characters and contains 0 dialog elements, 0 elements marked as a live region for announcements, and no "are you sure" wording anywhere. The spinner says only Converting…. The only place the word "leave" occurs at all is the sentence about your photo: "Your photo never leaves your device."
I converted three photos in one tab and then closed it, checking before and after whether each finished JPG could still be read out of memory.
| Photo handed in | Conversion | JPG produced | Readable before closing | After closing |
|---|---|---|---|---|
| 41,465 B, 700 × 476 | 716 ms | 38,078 B | yes | Failed to fetch |
| 41,465 B, 700 × 476 | 177 ms | 38,078 B | yes | Failed to fetch |
| 11,084,868 B, 4,032 × 3,024 | 5,634 ms | 3,177,680 B | yes | Failed to fetch |
That is 3,253,836 bytes — 3.1 MiB — of finished work, and 6,527 ms of it, dropped by one click on the tab's close button. The big one is the painful case: a 12-megapixel photo takes seconds to decode on this machine and produces three megabytes of JPG, and none of it is anywhere afterwards. Reopening the converter gives you the empty page, not your result.
Pressing Download JPG hands the file to the browser, and from that moment the page is not involved. I converted the same 12-megapixel photo three times and left immediately after clicking download:
| What I did after clicking download | File that landed on disk |
|---|---|
| Waited, did nothing else | 3,177,680 B |
| Navigated to another page immediately | 3,177,680 B |
| Closed the tab immediately | 3,177,680 B |
All three landed complete and byte-identical. So the practical rule is short: the JPG exists only between the moment the conversion finishes and the moment you press download, and the tab is not obliged to tell you that the window is open.
To be sure my dialog counter was not simply missing things, I added a beforeunload handler to the live page myself and repeated the exits.
| Case | Dialogs raised |
|---|---|
| The page as it is, clicked once, then left | 0 |
| Handler added, page never clicked, then left | 0 |
| Handler added, page clicked once, then left | 1 (beforeunload) |
| Handler added, page clicked once, tab closed | 1 (beforeunload) |
Two things come out of that. First, the detector works — with a handler installed and one click on the page, Chrome does put a dialog up, both for leaving and for closing the tab. Second, even then Chrome only shows it after you have touched the page: with the handler installed but no click, the navigation went through silently. So a warning on this site would not only have to be written, it would also depend on you having interacted with the page first.
One more detail worth knowing: I set the handler's text to "Your JPG is not downloaded yet!", and the dialog that came back carried an empty message string. Chrome writes that box in its own words; a site cannot put its own sentence in it.
After closing a tab that held a finished conversion, the next tab was ready in 236 ms and showed nothing: result area hidden, info line empty, the download link carrying no href of its own and no download name, and no preview loaded. There is no "you had a file" banner and no stored copy to restore — the page keeps nothing in browser storage, which is what the mid-conversion interruption measurements found too.
One curiosity I want to report accurately rather than usefully: after navigating away and coming back, the finished JPG was often still readable in memory — 14 of the 16 times I tried, including after a trip to another website and when read from a second tab while the first was still open. It was not dependable: one attempt came back empty after 5 seconds away and another after 30 seconds, so I could not find a rule for when it disappears and I am not going to invent one. Reloading the page killed it, and closing the tab killed every file I checked afterwards. None of this helps you: the result area is empty when you get back, so there is nothing to press.
Not in anything I measured. That box is raised by the browser on behalf of a page that has asked for it, and this page has not asked: beforeunload appears 0 times in the HTML, window.onbeforeunload is null, and all five exits produced 0 dialogs. When I installed a handler myself, the box appeared — so the absence is the page's choice, not the browser's.
I did not test that. My automation closes tabs through the debugging protocol, not the window through the close button, and I would rather leave it empty than guess. What I can say is that the trigger would be the same handler, and there is none.
I measured Windows and Chrome 153 only. The underlying fact — no handler, therefore no prompt — comes from the page's own code, so I would expect the same anywhere it runs, but I did not measure a phone browser or another browser today and am not going to assert it.
No. The fresh tab came up with an empty result area, an empty info line and an empty download link, and the page keeps nothing in local or session storage. Your original HEIC is untouched on your device, so the cheapest recovery is simply converting it again — 716 ms for the small photo, 5,634 ms for the 12-megapixel one.
In my measurements yes: 3,177,680 bytes landed in all three cases, including the one where the tab was closed in the same instant. I tested one photo size and left immediately; I did not test a slow disk, a download folder prompt, or many files at once, so I will not claim more than the three runs I made.
No prompt either way — leaving mid-conversion also raised 0 dialogs — but the work is lost rather than the result. Since a 12-megapixel photo takes seconds here, that is the version of this mistake that costs the most time.
Try it: open the converter, drop in a photo, and press Download JPG before you do anything else — it is the only step that outlives the tab.
First published: 7 October 2026