GIF was finalised in 1989, four years before the first graphical web browser. It is limited to 256 colours per frame, its transparency is a single on/off flag, and for animation it is comprehensively beaten by video formats that are a fraction of the size.
It is also still in daily use, still required by a surprising number of systems, and still the only thing that will do in specific situations. Knowing which situations those are saves you from two mistakes: reaching for GIF out of habit, and refusing to use it when it is the right answer.
What GIF actually is
Three design decisions from 1987 explain how GIF behaves today.
A 256-colour indexed palette. A GIF does not store a colour for each pixel. It stores a palette of up to 256 colours and then, for each pixel, an index into that palette. For an image with few distinct colours this is remarkably efficient, at one byte per pixel instead of three. For a photograph with tens of thousands of distinct colours it is a hard ceiling that cannot be raised.
Lossless LZW compression. Within the palette constraint, GIF is lossless: the indices are compressed with a dictionary algorithm and reconstructed exactly. This is why GIF handles flat colour and repeated patterns well and photographic noise badly. Noise has no repetition to compress.
Multiple frames in one file. Each frame carries its own palette and delay. This feature made GIF the animation format of the web for thirty years, essentially by accident.
Why photographs convert badly
When you convert a photo to GIF, the encoder must reduce potentially millions of distinct colours to 256. That process is called quantisation, and it is where the damage happens.
A good encoder builds the palette from your specific image instead of using a fixed set. It analyses which colours are actually present and allocates the 256 slots where that image needs them, so a photo of a forest gets a palette full of greens and a screenshot gets a palette full of greys. This helps enormously, and it is what the converter on this site does.
It cannot fix a smooth gradient. A clear sky might contain 5,000 distinguishable shades of blue across the frame. Reduced to perhaps 40 blues in the palette, the smooth transition becomes visible bands, distinct stripes where the gradient jumps from one available shade to the next. Skies, studio backdrops, skin tones and soft shadows are where you will see this first, and no setting avoids it, because the limit is structural.
The second surprise is size. Converting a JPG to GIF almost always produces a larger file. JPEG’s lossy compression is far more efficient for photographic data than a palette-indexed lossless format. If you are converting to GIF, you are buying compatibility and paying in both quality and bytes.
What converts well
The picture flips completely for images that were never photographs:
- Logos and flat-colour graphics often have fewer than 256 distinct colours to begin with, which means quantisation is lossless for them. The palette simply holds every colour the image contains.
- Screenshots of text and interfaces have large flat regions and a limited colour set, which LZW compression handles very well.
- Line art, diagrams, charts and pixel art are exactly what the format was designed for.
If your source is one of those, GIF conversion is close to free. The result may even be smaller than the PNG.
The transparency limitation
GIF supports transparency, but only as a single on/off flag. One palette entry is marked transparent, and a pixel either uses it or does not. There is no partial transparency.
Modern graphics are anti-aliased, so the edge of a letter or a curve is a band of partially transparent pixels blending the shape into the background. GIF cannot represent that band. Each of those pixels must become either fully opaque or fully gone, which produces the jagged, stair-stepped edges familiar from 1990s web design, plus a pale fringe wherever the anti-aliasing had been blended toward a background colour that is no longer there.
This is covered in more depth in transparency and image conversion. If soft edges matter, GIF is the wrong format.
Where GIF still genuinely wins
Systems that demand it are the honest majority of cases. Older forums, some email marketing platforms, legacy CMSes, certain government and institutional upload forms and some print-shop intake systems all fall here. When the field says “GIF only”, arguing with it is not a strategy.
Universal decode is the second case. No device made in the last thirty-five years fails to open a GIF. If you genuinely do not know what will be reading your file (an embedded display, an ancient kiosk, a system you have no documentation for), GIF is the safest bet available.
Pixel art and small flat graphics are the third. For content that is already palette-based, GIF is efficient, lossless and universally supported, and it is no compromise at all.
Chat and platform behaviour is the fourth. Several messaging platforms and forums treat
files with a .gif extension differently, autoplaying them, showing them inline, or
listing them in a separate picker. That is a platform decision and not a format
property, but it is a real reason a GIF is sometimes what you need.
Where it does not, and what to use instead
| If you were reaching for GIF because… | Use instead |
|---|---|
| You need a small photo for a web page | WebP, or JPG |
| You need transparency with soft edges | PNG, or WebP |
| You need a short looping animation | MP4 or WebM video |
| You need a logo that stays sharp at any size | SVG |
| You need a lossless working copy | PNG |
The animation row deserves emphasis. A five-second animated GIF at a reasonable size runs to several megabytes. The same clip as MP4 or WebM is commonly 95% smaller, at higher frame rates, with better colour, and with support in every browser. Every major platform that shows you a “GIF” (the search pickers built into messaging apps, the reaction libraries) is serving you a video file with a GIF-shaped label on it. They switched years ago for exactly this reason.
If you want a GIF-like experience on your own page, use a <video> element with
autoplay muted loop playsinline. It behaves the way a GIF does and costs a fraction
of the bandwidth.
Converting to GIF here
On this site, GIF is the one output format the browser cannot produce natively, since browsers read GIF but refuse to write it. A small open-source encoder running in the page handles it alongside everything else. It builds the palette from your actual image and uses no fixed swatch, which is what keeps logos and screenshots clean.
Two things it does not do: animation (a multi-frame source is converted from its first frame) and 1-bit transparency (transparent areas are flattened onto white, which is more predictable than a ragged cut-out). Both are noted on the route pages themselves.
Routes into GIF: JPG → GIF, PNG → GIF, WebP → GIF.
Summary
GIF is a compatibility format now. Use it when something specifically requires it, when the destination is genuinely unknown, or when your image is flat-coloured enough that the 256-colour limit costs nothing. For everything else, and especially for animation, something newer is smaller and better, and has been for years.