This is a question that I have been asking myself for a while and I have not found an answer.

Is it because of licensing issues? Because of the file format? Some other reason?

  • 4
    Because .gif is a strange collection of many formats and no one bothered building support for it into pdfLaTeX (would have to be done similar to how png is handled, because, afaik, gif can't be directly put into the pdf unlike some other image formats).
    – Skillmon
    Jan 26, 2021 at 9:02
  • 1
  • 7
    jpg and pdf can be fairly easily embedded in pdf gif can not. Nor can png but at least png is just a single bitmap that can be converted to a pdf bitmap converting gif to a video format embeddable in pdf is tricky (and has changed over time as video in pdf support has been somewhat variable) so is much better left to an external program. Jan 26, 2021 at 9:06
  • 1
    Wasn't gif also covered by patents for many years?
    – daleif
    Jan 26, 2021 at 10:06
  • 1
    @DavidCarlisle iirc, gif was original just a container format, and the animated gifs were added to that, so gif can also be "just a single bitmap", but doesn't have to. Handling gif correctly seems much more complicated :)
    – Skillmon
    Jan 27, 2021 at 9:28

2 Answers 2


Just to prove the opposite: Direct embedding GIF is possible, though not in PDF, yet in SVG output.

We just have to add a graphicx rule that treats GIF (static/animated) as another bitmap format (besides PNG and JPEG) with a user-provided <img file base name>.xbb file containing the bounding box information:


For a 480px * 360px image, the contents of the xbb file reads

%%BoundingBox: 0 0 480 360

For in-lining GIF data into the SVG output, the GIF file must be base64 encoded. Package media4svg provides a command for this that we make use of to modify the graphicx driver code for bitmaps (\Ginclude@bitmap).

Typeset example.tex listed below with

dvilualatex example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example


latex --shell-escape example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example

or even

xelatex --shell-escape --no-pdf example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example.xdv

N.B. Firefox fails to play animated GIF embedded in SVG that is itself embedded in a web page (like TeX.SX). It looks like a bug. Use a Blink-based web browser instead, such as Chromium, Chrome, Opera or Edge. Or (right-)click on the image to open the SVG in a browser tab of its own.

Input file example.tex.

(Download GIF from https://upload.wikimedia.org/wikipedia/commons/d/d3/Newtons_cradle_animation_book_2.gif)


% download `Newtons_cradle_animation_book_2.gif' before typesetting:
% https://upload.wikimedia.org/wikipedia/commons/d/d3/Newtons_cradle_animation_book_2.gif


% provide BoundingBox information in a separate .xbb file
%%BoundingBox: 0 0 480 360

% modified dvisvgm graphic[sx] driver for phys. bitmap embedding
\RequirePackage{media4svg} % provides base64-encode utility


\section{Animated GIF}


There is an article in TUGboat from 1996 (written by by Keith Reckdahl) that includes a discussion of supporting image formats. The article is from Volume 17 No. 1 and is called Using EPS Graphics in LATEX2ε Documents Part 1. The discussion is centered around dvips, but a similar argument can be made for direct pdf output (see David's comment on this question). Also the historical practise of not implementing direct support in dvips may have influenced choices made for pdflatex and later compilers.

Quote (page 52-53):

10.3 Including Non-EPS Graphic Files

While it is easy to insert EPS graphics into LATEX documents, it is not as straightforward to insert non-EPS graphics (GIF, TIFF, JPEG, PICT, etc.).


10.3.1 Direct Support for Non-EPS Graphics

It is often requested that LATEX and dvips support the direct inclusion of non-EPS graphic formats, making it as easy as inserting EPS files. While this would be convenient, there unfortunately are some problems which complicate things.

For example, most non-EPS graphic formats use binary files which cannot be read by TEX, which prevents LATEX from determining the size of the non-EPS graphics. Furthermore, supporting non-EPS graphics would also require dvips to incorporate graphics conversion capabilities (GIF-to-PS, TIFF-to-PS, etc.). This would not only require a lot of programming, it would also require more maintenance in the future.

Rather than directly incorporating graphics conversion routines, dvips provides a mechanism of calling external conversion programs. This mechanism can be accessed from LATEX by use [of] the command argument of \DeclareGraphicsRule. This has the benefit of being more flexible than direct support, and since it keeps the graphics conversion uncoupled from the DVI-to-PS conversion, users are free to choose their own graphics conversion program.

Another interesting historical approach is described in an article from 1991, where photos in GIF format are converted into a font (!) for direct inclusion into LaTeX documents.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.