On this site, no — and I counted every byte to be sure. Below is the actual traffic from three conversions, measured at the socket level.
Short answer: no. I put a byte-counting proxy between Chrome and the internet — every byte in and out had to pass through it — then converted three HEIC files of 41,465, 1,246,105 and 5,500,728 bytes. Bytes sent to heicjpg.dev during those three conversions: 0, 0 and 0. The smallest one sent nothing out of the machine at all in its 3,712 ms window — not to the site, not to anyone.
The measurement is not blind. As a control I posted that same 41,465-byte file to a local endpoint through the same proxy, and the counter recorded exactly 41,465 bytes in 8 ms. So when the counter reads 0 during a conversion, it means nothing was sent, not that nothing was seen.
Each row is one file, dropped into the converter in a clean Chrome profile with no extensions. The window opens when the file is handed to the page and closes three seconds after the JPG appears.
| File | Size in | Conversion | JPG out | Bytes out of the machine | …of which to heicjpg.dev |
|---|---|---|---|---|---|
sample.heic (700×476) | 41,465 | 705 ms | 38,078 | 0 | 0 |
photo_4032.heic (4032×3024) | 1,246,105 | 3,977 ms | 1,890,014 | 605 | 0 |
noisy_4032.heic (4032×3024) | 5,500,728 | 6,703 ms | 4,209,166 | 3,413 | 0 |
The two non-zero figures are not the photo. In the 1,246,105-byte run, the entire 605 bytes went to www.google-analytics.com — a one-line analytics beacon. In the 5,500,728-byte run, 575 of the 3,413 bytes were that same beacon and the remaining 2,238 were Chrome's own background chatter to its own services, which shows up identically in windows where I do nothing at all: over an idle 8 seconds the machine still sent 10,590 bytes, all of it to update.googleapis.com, android.clients.google.com and mtalk.google.com.
I ran the whole set twice. The second pass gave 834 ms and 0 bytes out for the small file, and 6,737 ms with 2,843 bytes out (606 of them the analytics beacon) for the 5,500,728-byte one. Same picture both times.
A marketing line saying "no upload" is worth nothing on its own, so here is the setup, in three independent layers:
fetch, XMLHttpRequest.send, navigator.sendBeacon and WebSocket. During the conversion of the 41,465-byte file, the page called none of them. Zero calls, not zero large calls."No upload" is not the same as "no requests". This page runs analytics, and you should know exactly what goes out:
https://www.google-analytics.com/g/collect with a 0-byte body — the measurement ID, client ID and page details ride in the query string. 605 to 606 bytes on the wire including TLS overhead.https://heicjpg.dev/cdn-cgi/rum carrying 836 bytes of JSON. I read it: it contains page-load timings, the browser version, the JS heap size and the page URL. No pixels, no file name, no image data.Both fire at page load — 1.5 and 1.7 seconds in — not when you convert. The analytics beacon also appears in windows where I did nothing (605 bytes during one idle 8-second stretch), and the Cloudflare report never appeared in any conversion window at all.
One honest limit: these requests are encrypted in transit, so a counter sees only their size. What I quoted above comes from the request objects before they are encrypted, which is how I can say the analytics body is empty rather than "probably small".
Cut the network entirely, then convert. After the page had finished loading, I blocked every URL the browser was allowed to request. The conversion still finished in 688 ms and produced net-blocked-copy.jpg — 37 KB. Bytes out during that window: 0. Bytes in: 0. A converter that needed a server cannot do this.
Watch for a delayed upload. Uploading later, in the background, would defeat the point. So after one conversion I clicked download and then watched for 30 seconds. Traffic to heicjpg.dev in those 30 seconds: none. The page made two blob: requests, which never leave the browser, and one analytics POST. In that same window Chrome pulled 36,921,317 bytes from its own optimisation-guide service — the counter recorded every byte of it, which is the other half of the proof that it is watching the right thing.
Something has to be downloaded, otherwise there would be no decoder. It all happens before you pick a file: the first load pulled 697,443 bytes from heicjpg.dev, of which the decoder heic-to.js accounts for 679,228 bytes transferred — 2,999,737 bytes once unpacked in memory. The page was ready to convert 1,529 ms after I asked for it. After that point, the site's own domain is silent for the rest of the session. (I wrote up that download separately in what the decoder actually is.)
The JPG itself is created inside the page as a blob: URL. Clicking download produced no network request at all — 0 bytes to any site, and the only bytes in that window were Chrome's own.
The thing to look for on any other converter is a request carrying roughly your file's size, or any /upload, /convert or API-looking URL. On this page the only URLs ever fetched from the site are the page, the stylesheet, the decoder, the icon and Cloudflare's timing endpoint.
No. Nothing went to Google from the conversion — the 605 bytes that left during the 1,246,105-byte run were an analytics beacon with an empty body, and it fires whether you convert anything or not.
It means your image data is not transmitted. Analytics and a page-timing report still run, and your browser still talks to the site to fetch the decoder once. Those are not your photo, but they are not nothing either.
No. All the conversions above ran at the page's default quality setting, and quality only affects how the JPG is written inside your browser. I measured no difference in network behaviour.
Size made no difference to what was sent. The 5,500,728-byte file is the largest I measured here and it still produced 0 bytes to the site; if it were being uploaded, the counter would have shown millions of bytes leaving, as it did in the control test.
The network behaviour does not depend on the file's contents — I have measured damaged files as well (see what happens with a corrupt HEIC) and the page still sends nothing.
Try it: open the converter, then check the Network panel while it works. Nothing should appear.
First published: 2 October 2026