2026-08-27

Why GIFs are grainy and huge — and how to make one from your photos anyway

In 2022, the biggest GIF platform on earth argued — in an official regulatory filing — that the GIF was dying. Fighting to keep its roughly $400 million acquisition by Meta alive, Giphy told the UK's Competition and Markets Authority that GIFs "have fallen out of fashion as a content form, with younger users in particular describing GIFs as 'for boomers' and 'cringe.'" It didn't work: the regulator forced a sale anyway, and in 2023 Meta handed Giphy to Shutterstock for $53 million — roughly an eighth of what it had paid. And yet here we are in 2026, and GIFs still autoplay in every chat thread, every project README, every forum reply. If you've ever wondered why the format everyone keeps declaring dead won't die — and why every GIF you make comes out a little grainy and a lot heavier than it looks — both answers live in a file format designed in 1987. Knowing them also tells you exactly how to make a better GIF from your own photos.

A format from 1987 that outlived its own obituary

CompuServe published the GIF format in June 1987, for a world of dial-up modems and 8-bit displays; the revision still in use everywhere today, GIF89a, followed two years later and added the timing and transparency controls that make animation possible. The specification — a plain text file, CompuServe copyright notice and all — is still hosted by the W3C. The reason a file format older than the web itself survives every obituary is simple: a GIF isn't really a video, it's an image that moves. It loads anywhere an ordinary image loads — forum posts, chat apps, documentation, README files, ancient CMS upload forms that reject video — and it plays by itself, silently, with no player, no codec question, and no play button. Nothing else does that, which is why nothing has replaced it.

Why GIFs look grainy: any frame gets 256 colors, total

The grain isn't your tool being sloppy — it's the spec. A GIF stores colors in a palette (the spec calls it a color table), and that table holds at most 256 entries. A photo from your phone is 24-bit color: it can use any of roughly 16.7 million shades, and a single sunset sky can easily contain more distinct colors than an entire GIF is allowed. So every GIF encoder, no matter how good, has to do the same brutal triage: pick the 256 colors that represent the image best, then snap every pixel to the nearest one. Flat graphics — screenshots, logos, text, UI — survive this almost untouched, which is what the format was designed for in 1987. Smooth photographic gradients don't: skies, skin, and shadows band into visible steps. That's the grain, and it's the same in every GIF tool ever written, because it's the format's rule, not the tool's.

Why GIFs are so huge: it was never a video format

A real video codec spends almost all of its cleverness between frames — storing one full picture and then, for the next, mostly just "what moved." A GIF does none of that. Every frame is stored as another complete indexed image, squeezed only by LZW — a general-purpose compression scheme published in 1984 — with no motion prediction of any kind. The result is measurable. Google's web.dev performance guidance, which flatly recommends websites replace animated GIFs with video, measured one short clip in all three containers: 3.7 MB as a GIF, 551 KB as an MP4, 341 KB as WebM. Same pictures, same motion — the GIF is roughly ten times the size. The same article points out the open secret of the modern web: on services like Imgur or Gfycat, the thing labeled "GIF" is usually an actual video file wearing the name, precisely because serving real GIFs at scale is so expensive.

One clip, three encodings: the GIF weighs roughly ten times the equivalent video, because GIF stores every frame as a complete image with no inter-frame compression. Source: Google web.dev, "Replace animated GIFs with video."

Why GIFs loop forever: an eleven-character ghost of Netscape

Here's the strangest part of the whole format. The GIF89a spec's animation controls say how long each frame shows — but contain no instruction for looping. Played strictly by the 1989 book, an animated GIF runs once and stops. Infinite looping was bolted on later through the spec's generic "application extension" escape hatch, in a block that identifies itself with the literal characters NETSCAPE2.0 — added so Netscape Navigator 2.0 could repeat animations, back in the mid-1990s. Every decoder since has simply honored it. Which means every looping GIF created today, including any you make in NearIMG, carries the name of a browser that died two decades ago in its bytes — eleven characters of the 1990s that the entire modern web still obeys.

Making a GIF from your photos, without uploading them

Most online GIF makers work the obvious way: you upload every frame to their server, the server encodes, and you download the result — often watermarked, always after your photos have left your machine. NearIMG's Make GIF tool does the entire job in your browser instead. Drop in several images, drag them into the order you want, and set three things: the frame delay (how long each picture holds), the output size, and whether it loops forever. The encoder underneath is a complete GIF89a implementation running on your device — it builds a single shared palette of up to 256 colors across all your frames, compresses them with the format's standard LZW, writes that Netscape looping block, and hands you back one animation.gif. Nothing is sent anywhere; the photos never leave your machine. Two honest details worth knowing: frames of different shapes are fitted onto a common canvas, so any leftover space is filled with white, and output width is deliberately capped at 800 pixels — for reasons the next section makes obvious.

Format-aware tips for a smaller, better GIF

Once you know a GIF stores every frame as a full image in at most 256 colors, the size and quality levers stop being mysterious:

Fewer frames beats everything. Ten frames is ten complete images; thirty is thirty. A photo slideshow GIF rarely needs more than one frame per photo — and each frame you cut shrinks the file almost proportionally.
Keep the width modest. Pixel count grows with width squared, and every one of those pixels is stored again in every frame. The tool's default of 360 pixels wide is sized for where GIFs actually live — chat windows and comment threads — and the 800px cap exists because beyond that, file size climbs fast for very little visible gain.
A longer frame delay costs nothing. Unlike video, a GIF's duration is free — the delay is just a number in each frame's header. A slower slideshow doesn't make a bigger file, so let each photo breathe.
Expect banding on photos, and don't blame the tool. Gradients — sky, skin, sunsets — will show 256-color steps in any GIF ever made. Graphics, screenshots, and text stay crisp. That's the 1987 contract.
If you need faithful motion quality, make a video instead. The honest rule from Google's own numbers: GIF wins when the file must behave like an image — autoplay in a README, a forum, a chat — and loses on pure quality-per-byte everywhere else.

The one-line version

GIFs look grainy because a 1987 spec caps any frame at 256 colors, and they're huge because the format compresses every frame as a separate complete image — Google measured the same clip at 3.7 MB as a GIF versus 551 KB as MP4 — while the infinite loop is an extension block still named after Netscape. Even Giphy told regulators GIFs are "for boomers," right before Meta had to sell it for $53 million; the format shrugged and kept autoplaying anyway, because nothing else works everywhere an image works. When you want one from your own photos, NearIMG's Make GIF tool encodes the whole thing on your device — drag the order, set delay, size, and loop — with no upload, no watermark, and no server ever seeing your pictures.