There is no lower limit that I could find. A 1×1 HEIC converts, and the JPG comes out 1×1 — same dimensions, no upscaling, no refusal.
Short answer: I could not find a size this converter refuses. I built HEIC files from 1×1 upward — 1×1, 2×2, 3×3, 1×2, 1×1000, 1000×1, 3×5, 15×1 — and ran 73 conversions on this site today. 71 succeeded. Every successful one came out at exactly the size the file declared, down to a single pixel. The two failures were files I had hand-edited so that the declared size no longer matched the coded image.
The real floor is not in the converter, it is in the file. Every HEIC I made with a dimension below 64 stores a 64×64 coded image plus a crop box that cuts it down. So a "1×1 HEIC" is physically a 64×64 picture with a note saying "only use the middle pixel". The decoder reads the note and the converter writes a true 1×1 JPG.
The catch is size on disk, not size in pixels. The smallest JPG I could get out was 757 bytes, and 753 of those bytes are headers — 474 of them a colour profile. So a 442-byte HEIC becomes a 757-byte JPG. Converting a tiny HEIC makes the file bigger.
I took one real iPhone photo (41,465 bytes, 700×476) and scaled it down to a series of tiny squares, then converted each one at the default quality setting. All of them succeeded. Times are per conversion; the first conversion in a fresh browser carries the decoder warm-up cost, which is why the 1×1 row is slower than the 64×64 row.
| Declared size | Source HEIC | JPG out | Time | Output size reported |
|---|---|---|---|---|
| 1 × 1 | 3,799 B | 761 B | 820 ms (first of session) | 1×1 |
| 2 × 2 | 3,839 B | 775 B | 64 ms | 2×2 |
| 3 × 3 | 3,864 B | 799 B | 61 ms | 3×3 |
| 4 × 4 | 3,872 B | 802 B | 77 ms | 4×4 |
| 5 × 5 | 3,872 B | 810 B | 83 ms | 5×5 |
| 8 × 8 | 3,889 B | 814 B | 109 ms | 8×8 |
| 16 × 16 | 3,981 B | 908 B | 64 ms | 16×16 |
| 32 × 32 | 4,262 B | 1,201 B | 81 ms | 32×32 |
| 64 × 64 | 4,956 B | 1,956 B | 18 ms | 64×64 |
I also ran the ladder sideways. A 1×1000 image came out 1,014 bytes and a 1000×1 came out 1,034 bytes, both with their dimensions intact. Odd sizes behaved the same: 3×5 → 801 B, 5×3 → 791 B, 7×9 → 826 B, 9×7 → 827 B, 15×1 → 788 B, 1×15 → 787 B. Nothing round, nothing aligned to a block boundary, nothing rejected.
None of my sub-64 files actually store a sub-64 picture. I opened every sample I built and read its box structure. The ispe box — the one that states the stored width and height — says 64×64 in all of them, and a second box, clap (clean aperture), carries the crop: "1/1" for the 1×1 files, "32/1" for the 32×32 files, and so on.
| Image you see | Stored size (ispe) | Crop box (clap) |
|---|---|---|
| 1 × 1 | 64 × 64 | 1/1 |
| 2 × 2 | 64 × 64 | 2/1 |
| 16 × 16 | 64 × 64 | 16/1 |
| 32 × 32 | 64 × 64 | 32/1 |
| 64 × 64 | 64 × 64 | none (no crop needed) |
| 1000 × 1 | 1000 × 64 | 1000/1 |
Note the last row: the short side is padded up to 64 as well. That is why a 1000×1 HEIC is 4,064 bytes rather than a few hundred. It is also why the converter can hand you a 1×1 JPG without any special-casing — by the time the decoder finishes, it has already applied the crop and is holding exactly one pixel.
I made five 1×1 files in solid colours. The smallest source file — a flat mid-grey, 442 bytes — produced the smallest output of the day: 757 bytes. Here is where those bytes go:
| Part | Bytes |
|---|---|
| Start-of-image marker | 2 |
| JFIF header (FFE0) | 18 |
| Embedded sRGB colour profile (FFE2) | 474 |
| Two quantisation tables (FFDB ×2) | 138 |
| Frame header (FFC0) | 19 |
| Four Huffman tables (FFC4 ×4) | 88 |
| Scan header (FFDA) | 14 |
| The actual picture data | 2 |
| End-of-image marker | 2 |
| Total | 757 |
The colour profile alone is 474 bytes of a 757-byte file — roughly two thirds of it — and it is written unconditionally. This converter attaches an sRGB profile to every JPG it writes, as I measured in what is inside the JPG. On a normal photo that is noise; on a 1×1 image it is the whole story.
Because of that fixed overhead, the usual "HEIC is smaller than JPG" intuition flips at the bottom of the range. These are all 1×1 or flat-colour files, converted at the default quality:
| Source | HEIC in | JPG out | JPG ÷ HEIC |
|---|---|---|---|
| 1×1 flat grey | 442 B | 757 B | 1.71 × |
| 1×1 solid black | 446 B | 759 B | 1.70 × |
| 1×1 solid red | 452 B | 762 B | 1.69 × |
| 16×16 flat blue | 454 B | 760 B | 1.67 × |
| 32×32 four colour blocks | 470 B | 780 B | 1.66 × |
The opposite happens when the tiny HEIC carries real detail. My downscaled photos are around 3,800–4,900 bytes because they were encoded from a photograph rather than a flat fill, and those come out at 0.20–0.40× their input size. So the ratio depends entirely on how much the source spent, not on how small the picture is.
All three quality settings produced a 762-byte file from the same 1×1 red HEIC. The bytes differ — the quantisation tables are different, so the three files have three different hashes — but there is nothing to quantise, so the size does not move.
| Source | 75% | 85% | 95% |
|---|---|---|---|
| 1×1 solid red | 762 B | 762 B | 762 B |
| 16×16 flat colour | 761 B | 760 B | 762 B |
| 32×32 flat blocks | 779 B | 780 B | 782 B |
| 16×16 photo detail | 877 B | 908 B | 983 B |
| 64×64 photo detail | 1,691 B | 1,956 B | 2,663 B |
The knob starts working the moment there is something to throw away. On the 64×64 photo it is a 1.57× spread between the lowest and highest setting — the same behaviour I measured on full-size photos in HEIC to JPG file size and speed.
I decoded each output JPG and compared its pixels with the source HEIC decoded on my own machine. At 1×1 the match is exact:
| 1×1 colour | Pixel in the HEIC | Pixel in the JPG |
|---|---|---|
| black | 0, 0, 0 | 0, 0, 0 |
| white | 255, 255, 255 | 255, 255, 255 |
| mid grey | 128, 128, 128 | 128, 128, 128 |
| red | 254, 0, 0 | 254, 0, 0 |
| blue | 0, 0, 254 | 0, 0, 254 |
That 254 in the red row is not the converter losing a value: the HEIC itself stores 254, which is what the HEVC encoder did to 255 before this site ever saw the file. The conversion round-trips whatever the file contains.
What does not survive is chroma resolution. Every output I parsed today is 4:2:0 with three components and a single 16×16 MCU — the same subsampling the converter uses at full size, as measured in how much quality the conversion costs. On a 1×1 image that costs nothing. On a 2×2 image holding four different colours it costs a lot: the source HEIC already decodes to muddy values (my red-green-blue-yellow block came back as roughly (78,80,15), (163,165,100), (41,43,0), (229,231,166)), and the JPG moves them further. Most of that damage is done when the HEIC is written, not by this converter — but if you ever need a 2×2 graphic to stay exact, neither format is the right container.
The conversion is correct and the preview is nearly invisible. The preview box is capped at 340 pixels tall and 100% of the column, but it never scales an image up, so a tiny JPG renders at its true size:
| Output | Natural size | Box painted on screen |
|---|---|---|
| 1×1 | 1 × 1 | 1 × 1 px |
| 16×16 | 16 × 16 | 16 × 16 px |
| 64×64 | 64 × 64 | 64 × 64 px |
| 1000×1 | 1000 × 1 | 703 × 1 px |
| 1×1000 | 1 × 1000 | 0 × 340 px |
| 700×476 (control) | 700 × 476 | 500 × 340 px |
A 1×1000 strip is fitted to the 340-pixel height cap, which makes it a fraction of a pixel wide, so it rounds to zero and disappears. The file is fine — the download button still hands you a correct 1,014-byte JPG — but do not use the preview to judge whether a very narrow image came out right.
Two of my 73 conversions failed, and both were files I had damaged on purpose to find the edge. I opened a 1×1 HEIC in a hex editor and rewrote the ispe box — the field that states the stored width and height — so it declared 0×0, and separately took a 64×64 file and declared it 1×1 without a crop box. Results:
| File | Result | Time (fresh page / warm page) | Message shown |
|---|---|---|---|
| ispe declares 0×0 | rejected | 871 ms / 8 ms | Could not convert this file. Make sure it is a valid HEIC or HEIF photo from an iPhone. |
| ispe declares 1×1 over a 64×64 coded image | rejected | 78 ms / 9 ms | same message |
| next file, a normal 1×1 | 762 B, converted | 142 ms / 71 ms | — |
I ran that group twice, once in a freshly opened browser and once after 23 other conversions, which is why there are two times per row — the rejection itself is quick, and most of the 871 ms in the first row is the decoder warming up. Both failures look identical on screen, and the browser console is the only place that distinguishes them ("HEIF image not found" for the first, "HEIF processing error" for the second) — the same split I found in the corrupted-file tests. A failed file does not poison the page: the very next conversion worked and produced the same 762 bytes as before.
I also tried to generate a genuine 0×0 HEIC with the encoder I use, and it refuses: "Empty images are not supported." Zero is not a size images can have, so there is nothing below 1×1 to test.
ispe: the four bytes at offset +8 are the stored width and the four at +12 are the stored height. A small-looking image that reports 64×64 is being cropped by a clap box.Not in any of the 71 successful conversions I ran. Output dimensions equalled the declared dimensions in every case, from 1×1 to 1000×1.
Yes, but the difference is small next to the fixed cost of a page load. After the decoder was warm, my tiny conversions took 18–109 ms each, while the first conversion in a fresh browser took 820 ms and a 12-megapixel photo takes seconds. For comparison, the largest file I have pushed through this converter is 108 megapixels, which I wrote up in how large a HEIC it can take.
Almost never. A photo from a phone is thousands of pixels on each side, far above anything in this article. This is an edge case — icons, sprites, test fixtures, or a file that has been downscaled to nothing — and it is worth knowing that the converter handles those without complaint even though the result is bigger than the input.
Yes, as far as I measured. I converted the 1×1 red file three times in a row and got 762 bytes with an identical SHA-256 hash each time; the 64×64 photo gave 1,956 bytes three times with an identical hash. That matches what I found on larger files in the determinism test.
Try it: open the converter and drop in the smallest HEIC you have. The result line will tell you its true size.
First published: 12 October 2026