Two different answers. A truncated or structurally broken file gets refused immediately — 25 of my 29 damaged files were rejected in 337–1,214 ms with one fixed sentence. But damage inside the image data is silent: 189 files with a single flipped byte all returned a JPG, and 184 of them were a different picture with no warning anywhere on the page.
Short answer: if your HEIC is cut short, has a broken header, or is not really a HEIC at all, the converter refuses it in well under a second and says "Could not convert this file. Make sure it is a valid HEIC or HEIF photo from an iPhone." It never hangs and it never produces a partial file. What it cannot do is detect damage inside the picture. I took one real iPhone photo, changed exactly one byte of it, and converted it: I got a JPG back, 700×476, no error, no warning. The picture inside was wrong — at the worst position I tried, the output was a 5,368 B file whose average brightness had collapsed from 39.7 to 1.2, a nearly black frame. That file looked like a success in every way the page reports success.
The practical rule: trust the error message completely, but do not trust a successful conversion as proof that your file was intact. Everything below was measured today on the live site.
Everything comes from one real iPhone photo: 41,465 B, 700×476. I read its container first — a 24 B ftyp box at the start, a 3,808 B meta box holding the index, and a 37,609 B mdat box holding the actual image data. Then I made 241 damaged copies of it by hand: cutting bytes off the end, cutting them off the front, zeroing whole boxes, flipping single bytes, and replacing the whole file with garbage. Each one went through the live converter in a real browser.
| What I did to it | Size | Result | Time |
|---|---|---|---|
| kept 99%, cut the rest | 41,050 B | rejected | 728 ms |
| kept 95% | 39,392 B | rejected | 820 ms |
| kept 90% | 37,319 B | rejected | 817 ms |
| kept 75% | 31,099 B | rejected | 492 ms |
| kept 50% | 20,733 B | rejected | 1,214 ms |
| kept 25% | 10,366 B | rejected | 593 ms |
| kept 10% | 4,147 B | rejected | 432 ms |
| kept 1% | 415 B | rejected | 532 ms |
| removed only the last byte | 41,464 B | rejected | 676 ms |
| removed only the last 8 bytes | 41,457 B | rejected | 678 ms |
only the ftyp box left | 24 B | rejected | 388 ms |
| only the first 32 bytes left | 32 B | rejected | 393 ms |
| removed the first 16 bytes | 41,449 B | rejected | 415 ms |
zeroed the whole ftyp payload | 41,465 B | rejected | 412 ms |
zeroed the whole meta index | 41,465 B | rejected | 447 ms |
| zeroed the whole image payload | 41,465 B | rejected | 519 ms |
| deleted the middle 50% | 20,732 B | rejected | 442 ms |
| 41,465 B of random bytes | 41,465 B | rejected | 337 ms |
| an empty file | 0 B | rejected | 398 ms |
| a plain text file renamed .heic | 1,160 B | rejected | 337 ms |
| put a JPEG magic number on the front | 41,465 B | rejected | 347 ms |
| flipped 38 bytes inside the image data | 41,465 B | converted — 4,618 B, wrong picture | 638 ms |
| added 4,096 B of junk to the end | 45,561 B | converted — 38,078 B, identical to the good one | 614 ms |
changed the brand tag to xxxx | 41,465 B | converted — 38,078 B, identical | 630 ms |
changed the brand tag to jpeg | 41,465 B | converted — 38,078 B, identical | 640 ms |
Two things stand out. Missing bytes are fatal at any size — even a file missing only its final byte was refused, so a half-finished download cannot be salvaged. Extra bytes are harmless: the good file with 4,096 B of junk glued on the end produced exactly the same 38,078 B JPG as the original. The brand tag changing is also irrelevant, which matches what I measured in the naming article — the decoder reads the image data, not the label.
All 25 rejections showed the identical message in the page, no matter whether the file was empty, truncated, or pure garbage: "Could not convert this file. Make sure it is a valid HEIC or HEIF photo from an iPhone." The page does not tell you what went wrong, or where.
It does write a more specific line to the browser console, and there are exactly two of them. Thirteen of my files produced Error: HEIF image not found, and twelve produced Error: HEIF processing error. The split is meaningful:
ftyp or meta was zeroed, pure garbage, the text file, and the smallest truncation (1% kept).If you want that detail, open the browser console before you convert and look for the line beginning heic-to error:. It is the only place the two cases are distinguished.
Nothing I threw at it hung. On a freshly loaded page the rejections took between 337 ms and 1,214 ms; once the page was warm, the same failures came back in 3–63 ms. The spinner always stopped, the result area always stayed hidden, and no partial file was ever offered for download.
The page also recovers cleanly. I ran good file, damaged file, good file, damaged file, good file, damaged file, good file in one page without reloading. Each damaged file was refused, and each good file that followed converted normally — 176 ms, 133 ms and 111 ms for the three that came after a failure, producing the same 38,078 B JPG as always. So a bad file costs you nothing but a few hundred milliseconds; you can pick the next one straight away. One detail worth knowing: after a failure the previous file's download link is still sitting in the page but the result area is hidden, so you cannot reach it through the interface.
This is the part that surprised me. I took the intact photo and changed exactly one byte inside its image payload — flipping all eight bits at that position and nothing else — then converted it. No error. A JPG came back at the correct 700×476, described by the page as s30000.jpg — 700×476 — 5 KB.
I then walked that single flipped byte along the image payload in 200-byte steps: 189 files, 189 conversions, zero errors. Every one produced a JPG. I compared each output against the correct conversion pixel by pixel, and 184 of the 189 were a different picture. Five positions (0, 13,000, 26,400, 29,600 and 37,600) happened to land somewhere that did not affect the result and produced the identical 38,078 B file.
| Byte flipped at | Output size | Mean error | Largest channel error | Average brightness (good: 39.7) |
|---|---|---|---|---|
| +500 | 19,513 B | 27.378 | 229 | 25.1 |
| +3,000 | 20,063 B | 25.519 | 224 | 26.7 |
| +8,000 | 26,284 B | 19.803 | 253 | 30.9 |
| +12,000 | 32,604 B | 15.890 | 246 | 33.8 |
| +24,000 | 35,274 B | 7.552 | 224 | 35.3 |
| +30,000 | 5,368 B | 36.610 | 224 | 1.2 |
| +34,000 | 27,942 B | 13.075 | 224 | 26.4 |
| +37,000 | 37,377 B | 2.513 | 184 | 37.2 |
| +37,600 | 38,068 B | 0.001 | 54 | 39.7 |
The worst one, at +30,000, is worth describing because it shows how complete the silence is. One byte out of 41,465 was changed. The output was 5,368 B instead of 38,078 B, its average brightness fell to 1.2, and 29.91% of its colour channels were off by more than 32 levels — a nearly black frame. The page presented it exactly like a success: correct dimensions, a download button, a filename, no error box.
Across the 184 silently wrong outputs, the spread was wide: 5 had a mean error under 1 (barely visible), 15 sat between 1 and 5, 87 between 5 and 15, and 77 were above 15. Output sizes ranged from 5,368 B to 39,231 B. Damage near the start of the image payload did the most harm; damage near the end barely registered.
No. Every truncation I made failed, from keeping 99% down to keeping 1% — including a file that was missing only its last byte. The converter rejects it in 337–1,214 ms.
No, the page shows one sentence for every kind of failure. The browser console is more specific: HEIF image not found when the container never yields an image, HEIF processing error when decoding fails.
Yes, and this is the real risk. 189 files with a single flipped byte all returned a JPG at the right dimensions with no error. 184 of them were a different picture from the correct conversion.
337 ms to 1,214 ms on a freshly loaded page, and 3–63 ms once the page is warm. Nothing hung, and the spinner always stopped.
No. I alternated damaged and good files four times in one page without reloading; the good file converted normally every time, at 176 ms, 133 ms and 111 ms.
No. Three damaged files converted twice each produced byte-identical output both times. The same damage gives the same wrong picture every run.
No. The intact photo with 4,096 B of random bytes appended converted to the same 38,078 B JPG in 614 ms. Missing bytes break a file; extra trailing bytes do not.
Compare its size with what you would expect, then open it. 152 of the 184 silently wrong outputs were at least 5% smaller than the correct file, but 12 were within 1% of it, so size alone is not a guarantee.
Try it: open the converter and convert a HEIC you suspect is damaged — if it is refused, the file has not been partly converted, and if it succeeds, check the picture before you trust it.
First published: 1 October 2026