GIF MIME Type – Free, Online, Private

What .gif is

GIF stores an indexed image of up to 256 colors per frame, compressed with LZW. The first six bytes are the ASCII signature GIF87a or GIF89a. GIF89a adds graphic control extensions, which is how animation and a single transparent index work. The file is a sequence of blocks ending with 3B. It is not a video even when it animates. There is no audio, no keyframe index a player can seek, and no color space beyond the palette. The registered type is image/gif for a still image and an animation.

IANA registers image/gif in RFC 2046. The media type is image/gif. Extensions that use it on this page: .gif. A client compares the type, not the filename, once the response has arrived. The filename still matters on disk and in Content-Disposition, which is why a wrong extension and a wrong header are two different bugs.

What sends image/gif

What sends image/gif: Send image/gif for a .gif file you actually want the browser to decode as an image. An img element animates a GIF89a on its own. A video element will not. If the animation is a recording of a UI, a video type such as video/webm or video/mp4 is smaller and can be paused by the browser's media controls. Keep GIF for the cases where a palette and a simple loop are the feature: a one-bit diagram, a reaction image, a compatibility fallback. Do not add a charset. The file on disk is still .gif. Once the response exists, a client trusts image/gif, not the filename. A static GIF87a and an animated GIF89a share the header. If you need a still preview for clients that do not animate, transcode the first frame to PNG and give that response its own URL and image/png. Do not serve the still frame as image/gif from the animated URL or caches will pin the wrong bytes.

Content-Type for .gif

Send image/gif and do not add a charset parameter. The body is binary. A charset tells a text decoder to reinterpret bytes that are not text, which corrupts a download and does not help a browser sniff the format.

Content-TypeContent-Type: image/gif

nginx, Apache, and Express

These snippets map .gif to image/gif. nginx reads the types block when it picks a type from the URL's extension. A location that sets default_type, or an application that sets the header itself, overrides that map. Apache AddType applies in the directory context where you put it. The Express static example writes the header for files ending in .gif so a stale mime database in the framework cannot disagree with the type on this page.

nginx# /etc/nginx/mime.types, inside the types { } block
image/gif                   gif;

ApacheAddType image/gif .gif

Expressimport express from "express";

const app = express();
app.use(express.static("public", {
  setHeaders(res, filePath) {
    if (filePath.endsWith(".gif")) {
      res.setHeader("Content-Type", "image/gif");
    }
  },
}));

Pitfalls for image/gif

Pitfalls that show up for image/gif, and not for a neighboring type with a similar extension: People rename an MP4 to .gif and send image/gif. The browser shows a broken image. Check the signature. Another trap is a types entry that maps .gif to image/gif and a CDN rule that compresses the body with gzip and then stores the result as the object without Content-Encoding. Clients inflate nothing and fail the LZW decode. A third is assuming transparency is a full alpha channel. GIF has one transparent palette index, so edges are hard. Use PNG or WebP when you need partial alpha.

• Netscape 2.0 looping is an application extension inside GIF89a. The type stays image/gif.
• Interlaced GIF is still image/gif. The interlace flag is in the image descriptor.
• LZW compression was the historical patent problem. The patent has expired. You do not need a different type to ship GIF.
• Serving GIF as image/png because a converter 'usually' outputs PNG will fail the moment the converter leaves the original bytes.