Yes. I deleted the source file before pressing download in nine out of ten scenarios — three of them while the conversion was still running — and all ten downloads landed.
Short answer: yes. Once the conversion has finished, the JPG exists in your browser's memory and the source file has nothing to do with it. I ran ten scenarios on the live page today: in nine of them I deleted the source HEIC — from outside the browser, the same way you would delete it in a file manager — before pressing download, and in three of those the deletion happened while the conversion was still running. All ten downloads landed on disk: six at 38,078 bytes and four at 3,177,680 bytes, with the same SHA-256 hashes as when the source was left alone.
The source file was never locked. All eight delete calls succeeded on the first try, including one issued 501 ms into a 12-megapixel conversion and one at 2,004 ms into another. I removed the whole source folder in one scenario too. No sharing violation, no "file in use" error — the browser reads what it needs and lets go.
How I measured it: today, in Chrome 153.0.8010.54 (headless, Windows, window 1280 × 900) against the live page, driving it through the DevTools protocol. Deletions were issued by a script outside the browser; each scenario used its own fresh copy of the source file, and the download folder was emptied before every single download.
Two source photos: the site's 41,465-byte sample and an 11,084,868-byte, 4,032 × 3,024 file. Deleted at counts from the moment the file was given to the page; conversion is how long the converter itself took.
| Scenario | Deleted at | Conversion | Deleted while converting? | JPG | Downloaded |
|---|---|---|---|---|---|
| Baseline — source left alone | — | 1,582 ms | no | 38,078 B | a1.jpg — 38,078 B |
| Small photo, deleted after | 1,939 ms | 435 ms | no | 38,078 B | a2.jpg — 38,078 B |
| Small photo, deleted, then waited 30 s | 963 ms | 263 ms | no | 38,078 B | a3.jpg — 38,078 B |
| 12 MP, deleted just after it finished | 5,849 ms | 5,785 ms | no | 3,177,680 B | b1.jpg — 3,177,680 B |
| Small photo, whole source folder removed | 211 ms | 180 ms | no | 38,078 B | a5.jpg — 38,078 B |
| Small photo, deleted, then waited 3 s | 543 ms | 144 ms | no | 38,078 B | a6.jpg — 38,078 B |
| 12 MP, deleted 501 ms in | 501 ms | 6,642 ms | yes | 3,177,680 B | c1.jpg — 3,177,680 B |
| 12 MP, deleted 2,004 ms in | 2,004 ms | 4,738 ms | yes | 3,177,680 B | c2.jpg — 3,177,680 B |
| 12 MP, deleted 4,070 ms in | 4,070 ms | 3,631 ms | no — it had finished at 3,631 ms | 3,177,680 B | c3.jpg — 3,177,680 B |
| Small photo, deleted 109 ms in | 109 ms | 220 ms | yes | 38,078 B | c4.jpg — 38,078 B |
Every small-photo JPG hashed to 93859de257dc44a7… and every 12-megapixel one to 56ee525f012aa19f…, deletion or not — the same hashes this site records for those two photos on other days. The download name still came from the source file's name in every scenario, including the ones where that file no longer existed.
The two are separate objects, and the measurements show it cleanly. After the source file was gone, the file the page had been handed was dead: its reported size dropped to 0 in all six scenarios where I checked, and asking the page to read it back threw NotFoundError in both scenarios where I tried. Meanwhile the result was untouched — the download button still pointed at a blob: URL in all ten scenarios, the preview still measured 700 × 476 or 4,032 × 3,024 as usual, the file label still read a2.jpg — 700×476 — 37 KB and its equivalents, and the error area stayed empty.
That is the whole mechanism in one sentence: the JPG is a blob the browser is holding in memory, not a pointer back at your HEIC. Deleting the HEIC removes the browser's ability to read the source again — it does not remove the result.
This is the case I most expected to fail, and it did not. In two scenarios the source file was removed 501 ms and 2,004 ms into 12-megapixel conversions that then ran for 6,642 ms and 4,738 ms — so the file was gone for nearly the entire decode. Both finished normally and both produced the identical 3,177,680-byte JPG, which downloaded intact. A third scenario on the small photo deleted the file 109 ms into a 220 ms conversion, with the same result.
What that tells you is that the decoder reads the file once and holds what it needs. It is not streaming the source in bits as it works.
Deleting the source is not one of them, but other things are, and I have measured them separately: reloading the page or closing the tab throws the result away, and nothing warns you first — that is the leaving-the-page measurement and the interrupted-conversion measurement. So the practical order is: convert, download, then tidy up. You can safely delete the HEIC the moment the conversion finishes, but do not reload before you have pressed download.
As far as the download goes, yes — nine of ten scenarios deleted the source first and all nine downloads landed. What you lose is the ability to convert that file again from the same page: its size reads 0 and reading it throws NotFoundError. Re-converting would mean picking the file again, which needs it to exist.
Measured twice on a 12-megapixel photo and once on the small one: the conversion completed and produced the same bytes it always does. The deletions landed 501 ms and 2,004 ms into conversions lasting 6,642 ms and 4,738 ms.
On this Windows machine, the file was never locked. Eight delete calls succeeded immediately, including while a 12-megapixel conversion was running, and removing the entire source folder at 211 ms also succeeded. I have no measurement from macOS, Linux or a phone, so I will not claim it for those.
Yes. Every download was named from the source file — a2.jpg, c1.jpg, b1.jpg and so on — even though the source no longer existed when the button was pressed. The name is decided at conversion time, not at download time.
I waited 30 seconds in one scenario and 3 seconds in another; both downloaded normally, and the page's state was identical after the wait. I did not test longer gaps, so I am not putting a limit here.
I did not measure memory today, so I will not say. What I measured is the file handle and the download — the result blob stays in memory either way.
I did not measure removable media. Every deletion here was a file on the same local disk; pulling a card out is a different failure, and I have no numbers for it.
Try it: open the converter, convert a photo, delete the HEIC from your disk, then press download — the JPG arrives.
First published: 7 October 2026