Convert HEIF to GIF

GIF has a hard palette limit of 256 colours. A photograph from a phone camera contains millions, so the conversion is not a re-encoding, it is a reduction — something has to decide which 256 colours the picture is allowed to keep, and everything else is approximated with one of them.

The result is worse than a JPG of the same picture and, on most photographs, larger than one. If nothing is forcing your hand, this is the wrong page and the JPG, PNG or WebP conversions are each better answers for a different reason. The rest of this page is written for the reader whose hand is being forced.

CompuServe published GIF in 1987 and the current specification, GIF89a, dates from 1989. That age is exactly why it persists: software written any time in the last thirty-five years understands it, and upload filters written a long time ago frequently list it alongside JPEG and nothing else.

The systems that produce this search are recognisable. An old message board. A wiki nobody has upgraded. An internal ticket system with a hard-coded allow list. A piece of retail or industrial software with a splash screen. In all of them the format is not a preference to argue with, and a converted GIF that looks slightly banded beats an upload that is rejected.

The naive approach — rounding each channel to a fixed grid — produces exactly the poster-like result people associate with old GIFs, because the palette has no relationship to the picture. This converter does not do that. It builds the palette from the colours actually in your image, partitioning the colour space and weighting by how often each region occurs, which is the same family of algorithm ImageMagick uses.

The consequence is that a picture dominated by a few hues comes out surprisingly well: a portrait against a plain wall, a product on a white background, a screenshot. A picture that spans the whole spectrum — a market stall, autumn foliage, a sunset over water — is where 256 entries run out and the reduction becomes obvious.

The palette is built from a reduced colour space rather than from the full precision of the source, which costs a little accuracy and saves a great deal of time. For a format that ends at 256 colours regardless, that trade sits heavily on the side of not making somebody wait seconds for a marginally better palette.

It is worth knowing because it sets expectations correctly. This is a fast, good-enough quantiser, not a slow perfectionist one. If you need the very best possible 256-colour rendering of a photograph — for a print of an old game asset, say — a dedicated tool with dithering options will beat it, and will take considerably longer.

Banding shows up first in gradients: a clear sky becomes three or four visible steps, a studio backdrop develops contour lines, skin tones go slightly blotchy across a cheek. Sharp detail — text, edges, foliage — survives much better, because those areas were never smooth to begin with.

The practical mitigation is size. Convert at a smaller maximum width and the same banding occupies fewer pixels and is far less noticeable, especially if the destination displays the image small anyway. Cropping to the part of the picture that matters helps for the same reason: fewer distinct colours competing for the same 256 slots.

Both formats can hold a sequence — GIF is the format most people associate with animation, and a HEIF container is allowed to store several images. Neither of those facts helps here. The decoder takes the primary image out of the container and the encoder writes one frame.

So a HEIF burst becomes a still, and there is no setting that changes it. If you are trying to produce an animation, the source you need is a video: the MP4 and MOV pages cover that, and they produce a real multi-frame GIF rather than a single picture in a format that could have held more.

HEIF carries a real alpha channel, where each pixel can be any degree of transparent. The GIF format offers one palette entry meaning "show the background through here", and the encoder on this page writes no such entry — so every pixel of the result is opaque, one bit included.

The alpha is resolved instead. Before the palette is chosen, the transparent areas are painted with the background colour set above the drop zone, white unless you change it, so an antialiased cut-out lands on a solid rectangle with its soft edge blended into that colour. It looks right on a page of the same colour and wrong on any other. If the cut-out has to work against a background you do not control, PNG is the conversion that keeps it, and it is one page over.

GIF compresses with LZW, which builds a dictionary of sequences of palette indices as it reads the image and reuses an entry every time that sequence recurs. That works beautifully on flat artwork and terribly on photographs, where adjacent pixels almost never match exactly even after quantisation. So the file is large despite holding less picture.

Set against a HEIF, which is a modern codec doing the opposite of that, the comparison is stark: it is common to end up with a GIF several times the size of the photograph it came from and visibly worse. That is not a bug in the conversion; it is what happens when a 1987 format is asked to hold a 2026 camera's output.

The format has no EXIF, no XMP and no place for GPS coordinates, and the conversion would not have carried them anyway — decoding to raw pixels and re-encoding leaves nothing for metadata to travel in.

For a picture going onto a public board that is a small mercy. The photograph you upload will not tell the forum where it was taken or which phone took it, and that is one fewer thing to remember to remove afterwards.

Both halves run in the browser tab, so nothing is uploaded, there is no queue and no account, and the 100 MB free ceiling applies per file to inputs no phone photograph will approach. A folder converts with a progress row each and an "all as ZIP" button once two are finished.

Keep the HEIF. The colours discarded to fit into a palette of 256 cannot be reconstructed from the GIF, and this site cannot write HEIF at all — the decoder it uses is licensed in a way a static site can honour, and an encoder is not. The GIF is a one-way copy for one stubborn system.

It is worth being fair to the format, because the fairness tells you when this conversion succeeds. GIF was designed for pictures made of a few flat colours: interface elements, diagrams, charts, logos, pixel art, screenshots of software with a limited palette. On those it is compact, exact and universally readable, and a 256-colour limit is not a limit at all because the picture never had more.

So the question to ask about your own file is not "is this a photograph" but "how many distinct colours does it really contain". A photograph of a whiteboard, a screenshot captured on a phone, a picture of a printed form: those are flat-colour images that happen to live in a camera container, and they convert to GIF far better than a landscape does.

Many systems that appear to demand GIF do not. An upload control that lists GIF first, an old help page, a colleague's habit — none of those is the actual validation rule, and the rule frequently includes JPEG and PNG as well. Trying one PNG upload costs a minute and can spare you the whole colour reduction.

Where the restriction is real, it is usually real in a specific way: a fixed pixel size, a maximum file size, or a system that only ever supported the format. Knowing which one you are up against changes what you do here — a size cap argues for a smaller maximum width, and a format-only rule means converting at whatever dimensions look best.