The page loads, looks ready, and then does nothing — without telling you why.
Short answer: no, it will not convert anything. With JavaScript disabled the page still loads and the upload area still looks clickable, but picking a photo produces nothing at all: no spinner, no error message, no result, and no network activity. There is no <noscript> notice on the page and no server-side fallback, so nothing explains the silence. What still works without JavaScript: every link on the site, and every guide page — they are plain HTML.
What I measured today on this site, in Chrome 153: with JavaScript on, the first load took 13 requests and 880,286 bytes, of which 679,995 bytes was the HEIC decoder. With JavaScript off, the same page took 3 requests and 11,366 bytes — the decoder was never fetched at all. That is 1.3% of the JavaScript-on load.
Two independent ways, both in Chrome 153.0.8010.54, both in a fresh browser profile so nothing was cached:
Both gave the same result, which matters: if only one of them had failed, the honest answer would be "it depends how you turn it off". It does not.
| JavaScript on (first visit) | JavaScript off | |
|---|---|---|
| Requests | 13 | 3 |
| Bytes transferred | 880,286 | 11,366 |
Decoder (heic-to.js) | 679,995 bytes | never requested |
window.HeicTo | "function" | "undefined" |
| Time to be usable | 3,386 ms | never |
| Console messages / errors | 0 | 0 |
The JavaScript-on load breaks down as 691,112 bytes from this site, 178,836 bytes from Google's tag loader and 10,338 bytes from Cloudflare's measurement beacon. The JavaScript-off load is only the page itself, the stylesheet and the icon:
| Request | Bytes |
|---|---|
/ (the page) | 5,793 |
/styles.css | 4,958 |
/favicon.svg | 615 |
The second way of disabling JavaScript produced 11,359 bytes across the same 3 requests — the tiny difference is HTTP header noise, not a different page.
This is the part I think is worth knowing. With JavaScript off, the drop zone is still there and still rendered — I measured it 288 px from the top of the page, laid out normally, with the text "Drop your HEIC photo here or click to browse". Nothing on the page is greyed out or marked as unavailable.
But the file input behind it carries the hidden attribute, and I confirmed its computed style is display: none. The only thing that can open the file picker is a click handler, and a click handler is JavaScript. So I clicked the drop zone with a real mouse event: nothing happened, and the URL did not change.
I then skipped the click and put a file straight into the input at the browser level, which is the closest you can get to "the user chose a photo" without script. The browser accepted it — the input held 1 file — and then, for six seconds, absolutely nothing occurred:
display: none);href;Not a slow conversion — a dead one. For contrast, the moment I reloaded with JavaScript enabled and handed it the same file, it produced sample-b.jpg — 700×476 — 37 KB in 855 ms.
Four things have to happen for a HEIC to become a JPG here, and every one of them is script:
change handler.There is also no <form> element anywhere on the page: I counted zero. A form is how a page would offer a non-JavaScript path — you would pick a file, press submit, and the browser would send it somewhere else to be converted. There is no such path here, and given that this converter's whole point is that your photo never leaves the device, one would not make sense.
I also counted zero <noscript> elements. That is the standard, one-line way for a page to say "this tool needs JavaScript". This page does not use it, so a visitor with scripting off gets an upload area that looks ready and no explanation.
I expected the JavaScript-off visit to still pull the 679,995-byte decoder and then fail to run it. It does not. Chrome does not request script files it is not going to execute, so with scripting off the browser fetched only the document, the stylesheet and the icon.
Practically: a visitor with JavaScript off downloads 11,366 bytes instead of 880,286. There is no wasted 679,995-byte download and no half-loaded tool — the page is simply an inert document. (What I did not check: whether other browsers behave the same way about skipping script downloads. I only measured Chrome.)
Two more measurements, because this is the part that would waste someone's evening:
window.HeicTo was still "undefined" and the file input still did nothing. Re-enabling does not run the scripts that were skipped; you have to reload the page.href was still empty, the info line was still empty, the spinner never appeared, and the console stayed empty. Even with everything downloaded, no script can run, so nothing happens.So the fix is always the same two steps: allow JavaScript for the site, then reload the page. Picking another file, or waiting, will not help.
The converter is the only part of this site that needs script. Everything written in prose is static HTML:
For reference, the page carries 5 <script> tags in total: 3 external (the decoder, the analytics tag, Cloudflare's beacon) and 2 inline blocks of 2,920 characters between them.
If nothing happens at all — no spinner, no error, nothing in the Console tab — you have reproduced what I measured. Then uncheck the box and reload, and it works again.
No. I counted zero <noscript> elements, so there is no message. The failure is silent: no spinner, no error text, and nothing in the console.
I did not test that, so I will not claim it. What I can say is that the decoder is served from this same site (a relative heic-to.js), not from a third-party domain, so a blocker that only targets third-party scripts has nothing obvious to block here. I ran no test with any blocker installed.
I could not test it, so this is a gap rather than a result: automation cannot produce a real file drag, and the drop path on this page is a drop handler, which is script. I verified clicking does nothing; I did not verify what a real drag does.
Yes, trivially — with script off the page made 0 network requests, so nothing could have been sent anywhere. The meaningful version of that claim is measured with JavaScript on, in the network-level test.
The mechanism is not: decoding a HEIC inside a browser means running a decoder, and running anything means script. Any converter that keeps your photo on your device needs it. I only have numbers for this site — see the browser support measurements for what else the browser has to provide.
Yes, and it needs the same thing: one online visit to fetch the decoder, then the network can be off. That is measured in the offline test — different question from this one, same prerequisite.
Try it: open the converter with JavaScript on, convert a photo, then disable JavaScript and reload to see the difference.
First published: 3 October 2026