GIFs Not Working in WordPress? Causes and Fixes for 2026

Introduction

You upload an animated GIF. It plays fine on your computer. You add it to a post, hit preview, and it sits there as one frozen frame. Or the upload fails with an error you have not seen before.

The reason is not obvious. In most cases the GIF is fine and WordPress is fine. What usually happens is that WordPress serves a resized copy of your image rather than the original, and that copy holds only the first frame. There are other causes too: optimisation plugins strip animation, upload limits reject large files, and some GIFs are built to play only once. Each produces a slightly different symptom, so the symptom points to the fix.

This guide covers what WordPress does to a GIF when you upload it, the realistic causes, what a broken GIF costs your site, how to find your specific fault, twelve fixes in order, and when a GIF is the wrong format for the job.

What Is the GIF Problem in WordPress?

A GIF is an image file holding many frames. The browser plays them in sequence, which is what makes it move. Unlike a video it has no play button, no sound and no controls.

Here is the part that causes most of the trouble. When you upload any image, WordPress also creates smaller copies at set sizes, such as thumbnail, medium and large, and your theme registers its own sizes on top of those. This normally helps, because it lets a phone download a small image and a desktop a large one.

Those copies are produced by the server’s image library, which reads the first frame, resizes it and saves it, discarding the rest. They are still valid GIF files and still appear in your media library, but they are single frames. They are frozen by design.

What the visitor sees. The image loads and looks correct. It is simply still. There is no error and no broken image icon, so most visitors assume the picture was always meant to be static.

What the admin sees. The GIF usually animates inside the media library, because that preview often points at the original file. You check the library, see it moving, and conclude the post is broken. In fact both are behaving as designed, and the post is pointing at a different file.

A second group of problems happens earlier, at upload. Animated GIFs are large, and a short clip can run to several megabytes. That size meets server limits a normal photo never touches, so the upload is rejected before WordPress resizes anything. Our guide on WordPress image upload errors covers the wider set of upload faults.

What Causes GIFs to Stop Working?

There are eight realistic causes. The first two account for most frozen GIFs, so check those first. The rest explain upload failures and the stranger cases.

WordPress served a resized copy. When you insert an image, the editor lets you choose a size. Anything other than Full Size gives you one of the static copies, because the animation was removed when that copy was generated. The fix is to point the post at the original file.

The featured image uses a cropped thumbnail. Featured images rarely use the original. Your theme registers a specific size, often cropped to a fixed shape, and requests that. Since it is a generated copy, an animated featured image will usually sit still. Our guide on featured images and post thumbnails explains how the theme picks a size.

An optimisation plugin stripped the animation. Compression plugins shrink every image on upload, and many flatten animated files as part of that, because one frame compresses better than fifty. If your GIFs stopped moving after you installed a compression tool, this is the likely cause.

Automatic WebP or AVIF conversion changed the file. Optimisation tools convert images to newer formats to save bandwidth. Those formats can hold animation, but many conversion routines carry only the first frame across, so the browser receives a valid still image. Our guide on using WebP images in WordPress explains how conversion works.

The GIF has a loop limit built in. A GIF stores how many times it should repeat, and that number is set when the file is created. Many export tools default to playing once. The animation then runs briefly the first time it scrolls into view and stops on the last frame, so anyone arriving later sees a still picture.

The visitor’s device is pausing it. Operating systems and browsers offer a reduced motion setting for people who find animation uncomfortable, and mobile data savers can stop animated images loading in full. Some browsers also pause animation in background tabs. In these cases your site is serving a good file and the viewer’s own settings are stopping it.

The file is too big, or the server ran out of memory. Your server sets a maximum upload size, and hosts often set it low, so a large GIF bounces off it with a message naming the limit. Resizing also loads the file into memory frame by frame, which produces a generic HTTP error instead. Our article on the allowed memory size exhausted error covers that failure.

The file type is blocked, or it is not really a GIF. Some security setups restrict which extensions can be uploaded, and on multisite the allowed list is controlled centrally. Separately, many things labelled “GIF” online are short silent videos. If you saved one and renamed it, WordPress will either reject it or store a file the browser cannot animate.

What Is the Impact of This Issue on the Website?

A frozen GIF looks like a small cosmetic fault, but it is usually more than that, because a GIF almost always carries information a still image cannot. When it stops moving, that information is gone from the page.

Your explanation stops working. Most GIFs on a business site are demonstrations, such as a screen recording of a setting being changed or a product in use. As a single frame, none of that communicates, and the reader is left with a screenshot and no context.

Tutorials lose value and support load rises. How-to content leans on motion to show a sequence of steps, and a frozen first frame often shows the starting state only. Readers then ask the question the article was meant to answer.

Page speed suffers. Animated GIFs are inefficient, and a five second clip can weigh more than a hundred photos. Even when it does not animate, the full file is often still downloaded, so visitors pay the bandwidth cost without the benefit. A heavy image near the top of a page also delays the point at which the main content appears, which search engines measure. Our guide on checking your WordPress site performance covers how to test this.

Accessibility suffers either way. A GIF cannot be paused, so a looping animation beside text is a problem for readers with motion sensitivity. A frozen GIF causes the opposite problem, because any meaning carried by the movement is now invisible and a still frame rarely has alt text describing a sequence.

Storage and confidence both take a hit. Failed and repeated uploads leave large files on the server. When uploads fail with unexplained errors, content teams also start avoiding images altogether.

How to Identify This Issue on the Website

Start by working out whether your problem is display or upload, because those are two different faults with two different fix paths. The signs below separate them quickly.

Sign: the image shows but never moves. The file uploaded and displays fine, so this is a display problem. Your post is most likely pointing at a resized copy rather than the original.

Sign: it animates in the media library but not in the post. This is the clearest confirmation of the resizing cause, because the library preview uses the original and the post uses a generated size. If only the featured image is frozen, your theme is requesting a registered thumbnail size for that slot.

Sign: it stopped animating on an old post. Nothing changed in the post, so something changed site-wide. Look at what you installed or enabled recently, particularly anything that compresses or converts images.

Sign: the upload is rejected. If WordPress names a size limit, that is a server setting rather than a fault. A plain HTTP error usually means memory or the image library, and our guide on fixing the HTTP image upload error narrows it down. A message about permitted file types points at a security restriction.

Once the symptom is clear, confirm it with these checks.

Open the image URL on its own and read the file name. Copy the image address from your post and paste it into a new tab. If it animates there, the file is fine and the post is pointing at the wrong copy. The file name settles it: a URL ending in dimensions is a generated copy, while the original has none.

Check the Content-Type in the Network tab. Reload the page with the Network tab open and click the image request. The response headers name the format the browser actually received. If you asked for a GIF and the type says WebP or AVIF, a conversion step is in play. If it says video, the file was never a GIF. Our guide on opening the browser console walks through these panels.

Compare the original and displayed file sizes. Note the size of the original in Media → Library, then the size of the file your post loads. A clip flattened to one frame usually drops to a small fraction of its original size, so a large gap suggests flattening rather than a display setting.

Check the loop count, then test a second device. Open the original in any tool that reports GIF properties and look at the repeat value. If it is set to play once rather than forever, the file is behaving correctly. If the loop count is fine, try the same URL on a colleague’s phone, since a reduced motion or data saver setting can stop animation.

Check Media Handling in Site Health. Tools → Site Health → Info → Media Handling names the image library your server uses, its version, and the maximum upload size. Those three values explain most upload failures. Our guide to Site Health explains the results.

How to Fix GIFs That Are Not Working

Work through these in order. The early steps are free, instant and reversible, and the later ones touch server settings.

Step 1: Back up before you change anything. Take a full backup of files and database, and make server-level changes on staging first. Our guides on backing up and restoring a WordPress website and setting up a staging site cover both.

Step 2: Confirm the original animates. In Media → Library, open the GIF and click the link to the original file. If it moves in that tab, this is a display problem, so steps 3 to 5 apply. If it does not move, go to step 6.

Step 3: Insert the image at full size in the block editor. Select the image, open the block settings panel, and change the Resolution or Image Size setting to Full Size. Update and reload. To confirm, inspect the image and check the file name no longer ends in dimensions.

Step 4: Do the same in the classic editor. Click the image, choose the edit pencil, and in Attachment Display Settings set Size to Full Size. The image tag should then point at a file name with no dimensions appended.

Step 5: Use a still image as the featured image. Featured images use a theme-registered size, so they usually stay frozen whatever you do. Put a still image in that slot and place the animation in the body instead. Our guide on featured images not showing correctly covers related faults.

Step 6: Exclude GIFs from your optimisation plugin. Open the plugin settings, find the file type list or exclusion rule, and switch GIF off. Then delete the affected file and upload a fresh copy under a new name, since a flattened copy cannot be recovered and a new name tells you which version you are testing.

Step 7: Turn off format conversion for GIFs. In the same plugin, disable WebP or AVIF conversion, or exclude GIF from it. Clear your cache afterwards, because converted copies are often cached separately. Our guide on clearing the WordPress cache explains the order.

Step 8: Exclude the GIF from lazy loading. Lazy loading delays images until they scroll into view, and a few setups swap the real file for a placeholder without swapping it back. Add the file to your exclusion list, or switch the feature off briefly to test.

Step 9: Test with your content delivery network bypassed. If you use one, purge its cache, then load the image from your own domain directly. If it animates from your server but not through the network, exclude GIF from image optimisation in that service.

Step 10: Test for a plugin conflict. Deactivate all plugins and upload a fresh copy. If it works, reactivate them one at a time until the fault returns. Our article on WordPress plugin conflicts explains how to run this safely.

Step 11: Raise the upload size and memory limits. Check the current figures under Tools → Site Health → Info → Media Handling. Most hosting panels expose these as PHP settings you can change from a dashboard, which is the safest route. Two settings work together, one for a single file and one for the whole request, and the second must be at least as large as the first.

Step 12: Check the image library and allowed file types. On the same screen, read the active image editor and its version, since one library handles animation better than the other. Ask your host to enable it or move you to a newer PHP release. If uploads are refused on security grounds, check your security plugin, and on multisite confirm gif appears under Network Admin → Settings → Upload Settings.

If the clip runs longer than a few seconds, converting it to MP4 or WebM is usually a better answer than any of the above. The file is often far smaller and loop count and flattening stop being issues. Set it to loop and mute it, since browsers block auto-play with sound.

How to Prevent This Issue

Most GIF problems are avoidable with a few settings and one habit, which is choosing the right format before you upload anything.

Choose video for anything over about three seconds. GIF was not designed for long animation. MP4 and WebM do the same job at a fraction of the size, with no risk of being flattened. Reserve GIFs for short, simple loops.

Keep GIFs small before uploading. Trim the clip, reduce the frame rate, and cut the dimensions to the size it will display at. A file already under your upload limit will not trip a size error.

Export with looping switched on. Check the loop setting every time, because most tools default to playing once. This removes the most misdiagnosed cause on the list and costs nothing at export time.

Set your optimisation exclusions once. Exclude GIF from compression and from format conversion today, before you need it. This stops a future upload being flattened while you are not watching.

Keep an unoptimised master copy off the site. Once a plugin flattens a GIF, no setting brings the animation back. Store the original export in your own file storage so re-uploading takes a minute.

Always insert at full size. Make this a standing rule for anyone adding animation, and write it into your editorial checklist. It removes the most common cause.

Test new plugins on staging and know your upload limit. Any plugin touching images, speed or caching can break animation, so install it on a copy first and confirm a test GIF still moves. Look up your upload limit once under Media Handling and note it where your team can see it.

Conclusion

A GIF that will not move in WordPress is rarely a broken file. In most cases WordPress is doing what it was designed to do: it generated smaller copies, those copies hold only the first frame, and your post is pointing at one of them.

The causes split into two groups. Display problems come from resized copies, theme thumbnail sizes, compression plugins, format conversion, lazy loading, delivery networks, a loop count set to play once, and the viewer’s own reduced motion settings. Upload problems come from the maximum upload size, the memory limit, the server’s image library, blocked file types, and files that were never GIFs.

Diagnosis is quick once you know where to look. Open the image URL on its own and read the file name, since dimensions in the name mean a resized copy. For upload failures, Media Handling in Site Health gives you the limit, the library and the version in one screen.

The fixes follow the same order: back up, confirm the original animates, insert at full size, exclude GIFs from compression and conversion, check lazy loading and your delivery network, then raise upload and memory limits. For anything longer than a few seconds, converting to MP4 or WebM addresses the animation and the page speed together.

If uploads still fail, the limit is usually on the server rather than in WordPress. If you would like someone to look at media handling, PHP limits or image library settings, 24×7 WP Support works on issues like this.