Usually yes. If your browser hands the page back from its forward/back cache, the finished JPG is still on screen — same bytes, same download link. Reload or retype the address and all of it is gone.
Short answer: yes, when the browser restores the page from its back/forward cache rather than loading it again. In today's test the whole finished state came back with it — the result panel, the file name, the size line, the preview, the quality setting, the file still selected in the input box, and the scroll position. The download link still handed back 38,078 bytes with the same SHA-256 as before I left.
What I measured today (15 October 2026) on the live site: I converted a 41,465-byte HEIC, navigated to another page, and pressed Back. The page came back in 66 ms with zero load events and 453 bytes of network traffic, and the browser told me so directly: the pageshow event fired with persisted = true, which only happens when a page is woken from the cache instead of rebuilt. Then I did the same thing from another website, five times in a row, and once in the middle of a conversion. Reloading and retyping the address both wiped everything.
There is one page and three routes to it. Only one of them keeps your result.
| Route | Time | Load events | Requests | Bytes | Result still there? |
|---|---|---|---|---|---|
| Back button (served from cache) | 93 ms | 0 | 1 | 448 B | Yes — same 38,078-byte file |
| Reload | 261 ms | 1 | 7 | 6,140 B | No — panel hidden, size line empty |
| Type the address again | 245 ms | 1 | 6 | 6,140 B | No — same empty state |
For scale, a cold first visit to the same page today cost 881,222 bytes across 5 requests and was ready in 1,824 ms. The back navigation cost 448 bytes. That gap is the whole story: nothing was rebuilt, so nothing was lost.
After the reload I converted again and it worked normally — 38,078 bytes in 713 ms. A reload costs you the result, not the tool.
I converted the same 41,465-byte HEIC, scrolled down 300 px, left for another page on this site, and pressed Back. Here is the before and after, read straight out of the live DOM:
| State | Before leaving | After Back |
|---|---|---|
| Result panel | visible | visible |
| Size line on screen | f1.jpg — 700 × 476 — 37 KB | f1.jpg — 700 × 476 — 37 KB |
| Download file name | f1.jpg | f1.jpg |
| Preview resolution | 700 × 476 | 700 × 476 |
| Quality setting | 0.85 | 0.85 |
| File still selected in the input | 1 file | 1 file |
| Scroll position | 300 px | 300 px |
| Bytes behind the download link | 38,078 | 38,078 — identical SHA-256 |
The last row is the one that matters. The download link points at an in-browser blob, and I fetched it after coming back: 38,078 bytes, hash 93859de257dc44a7…, the same value this file has produced on every run I have done on this site. It was not re-created; it was still there.
Leaving the site entirely is not different from opening a page on it. I converted, navigated to example.com, and pressed Back: 139 ms, zero load events, 445 bytes, persisted = true, result intact, 38,078 bytes still behind the link.
I also went two levels deep — home, then two other pages — and walked back twice: 42 ms to the first page and 48 ms to the converter, result and blob intact at the end. And pressing Forward then Back again kept it too: 43 ms back, 48 ms forward, 48 ms back, same 38,078 bytes at the end.
A single success could be luck. I did five back-and-forward cycles on one converted result and checked the blob every time:
| Trip | Back | Forward | Load events | Bytes | Result |
|---|---|---|---|---|---|
| 1 | 91 ms | 67 ms | 0 | 0 | intact |
| 2 | 43 ms | 37 ms | 0 | 0 | intact |
| 3 | 46 ms | 41 ms | 0 | 0 | intact |
| 4 | 48 ms | 48 ms | 0 | 0 | intact |
| 5 | 44 ms | 60 ms | 0 | 0 | intact |
Ten navigations, zero load events, zero bytes, and 38,078 bytes readable from the download link after every single one. The scroll position was 300 px after each return.
This is the case I expected to break, and it did not. I dropped an 11,084,868-byte HEIC (4032 × 3024), waited 1,500 ms while the spinner was still turning, and navigated away. When I came back the conversion finished and the result appeared on screen: f6.jpg — 4032 × 3024 — 3103 KB, 3,177,680 bytes, hash 56ee525f012aa19f….
| Run | Drop to result | Output |
|---|---|---|
| Left at 1,500 ms, came back about 3.4 s later | 10,380 ms | 3,177,680 B, 4032 × 3024 |
| Never left, run 1 | 9,238 ms | 3,177,680 B |
| Never left, run 2 | 5,845 ms | 3,177,680 B |
| Never left, run 3 | 7,107 ms | 3,177,680 B |
The interrupted run is the slowest of the four, but the file it left behind is byte-for-byte the same as the three uninterrupted runs. The work was paused while the page sat in the cache and finished when I returned; it was not thrown away and restarted.
None of this is a feature of this converter. I read today's homepage source — 13,930 bytes — and counted the words a page would need to manage its own history: history 0, pushState 0, popstate 0, replaceState 0, scrollRestoration 0, unload 0, beforeunload 0. At runtime window.onunload, window.onpagehide and window.onpageshow are all null, and history.scrollRestoration is the browser default, auto.
That is the honest answer to "does the site keep my result": the site does not keep anything. Whether you get your page back is decided entirely by your browser, and the browser's only reason to destroy the page would be a rule asking it to — of which there are none here.
One more measurement that matters for the Back button specifically: converting does not add history entries. The history list held 3 entries before converting, 3 after converting, and 3 after clicking Convert another. So Back never steps backwards through your conversions — it always leaves the page.
I ran the same "convert, leave, come back" test five times with different amounts of time away. Four came back from the cache. One did not.
| Time away | Back took | Restored from cache? | Result |
|---|---|---|---|
| 10 s | 54 ms | Yes | there |
| 30 s | 171 ms | No — a full reload | gone |
| 60 s | 76 ms | Yes | there |
| 30 s | 46 ms | Yes | there |
| 10 s | 58 ms | Yes | there |
The failure is not the longest wait — 60 seconds restored fine and a 30-second wait did not. I could not tie it to the length of time away, so I am not going to invent a threshold. What I can say is that the browser is free to drop a cached page whenever it wants, and when it does, you get the same empty state a reload would give you. Treat the surviving result as a lucky bonus, not as storage.
The failed return still cost almost nothing to load: 5 requests, 0 bytes, because everything came from the browser's own disk cache. It was a rebuild, not a re-download.
f4.jpg, 38,078 bytes.713 ms.Yes. I came back from another page and clicked the download link: the file landed as f4.jpg at 38,078 bytes. Coming back also left the converter usable — a fresh conversion right after the return produced the same 38,078 bytes in 354 ms.
Neither. The history list held 3 entries before converting, 3 after converting and 3 after clicking Convert another. Back always leaves the page rather than stepping through conversions.
Closing the tab is the same as a reload as far as the result is concerned — the finished JPG does not come back. I measured the closing case separately in Closing the tab with an undownloaded result, including whether anything warns you.
Yes, and unlike Back there is no resumption: a reload throws the in-flight conversion away with no message. I measured that in Reloading or switching away mid-conversion and in Cancelling a conversion that has already started, where reload turned out to be the only thing that actually stops one.
Yes — it is not re-encoded, it is the same blob. Every conversion of this file on this site produces the same bytes; I checked that across many runs in Converting the same HEIC ten times.
I did not measure them today, so I will not claim it. All of the above is Chrome 155.0.8059.40 on Windows, driven through the DevTools protocol's history navigation — the same path the Back button uses. Firefox and Safari have their own versions of this cache and may behave differently.
Either way, download before you close the tab. That is the only step I have measured as reliable in every case.
Try it: open the converter, convert a photo, follow a link away, then press Back.
First published: 15 October 2026