How to add animated GIFs to WordPress

Adding an animated GIF to a WordPress post sounds like it should be the same as adding a regular image, and most of the time it is. But there is one specific behavior that catches almost everyone off-guard the first time: WordPress strips the animation when it generates resized versions of the GIF, so if your post displays the image at any size other than the original upload size, you end up with a still frame instead of an animation. The fix is small, the diagnosis is the hard part.

This guide covers how to upload an animated GIF, why animation disappears at the wrong display size, the two ways to keep it intact, and the modern alternative (MP4 or WebM) that is roughly 10x smaller for the same visual result.

The short answer#

Upload the GIF the same way you upload any image – drag and drop it into the editor, use the Image block, or upload through the Media Library. To keep the animation working:

• Display the image at “Full Size” in the Image block’s right sidebar. This serves the original file, animation intact.
• Or upload the GIF at the exact pixel dimensions you want to display. If your post column is 800px wide and you upload a 1200px GIF, WordPress will resize it to fit and strip the animation in the process. Resize the GIF in your editor before upload.

For sites that use animated GIFs heavily, converting them to MP4 or WebM video is the better path – same visual result, 10x smaller files, and modern browsers play them inline like a GIF.

Why WordPress strips animation from resized GIFs#

When you upload any image to WordPress, the platform automatically generates several resized versions: thumbnail (150×150), medium (up to 300×300), large (up to 1024×1024), plus any sizes the active theme registers. The original file is kept too, but the resized versions are what most blocks and themes display by default.

The image-resizing libraries WordPress uses (GD and Imagick) handle GIF resizing by reading the first frame, resizing it, and discarding the rest. The resized file is technically still a .gif , but it has only one frame – no animation. This is not a WordPress bug; it is how the libraries work, and resizing every frame would multiply file size by the number of frames in the animation (often 30-60 frames for a typical reaction GIF).

The result: an animated GIF uploaded as 1200x800px gets resized into still 300×200 (medium) and 1024×683 (large) versions. If your post displays the medium size, the visitor sees the first frame as a static image and wonders why your animation is broken.

Fix 1: Display at "Full Size"#

The simplest fix. In the block editor:

1. Click the Image block containing the GIF.
2. In the right-hand sidebar, find the Image size dropdown.
3. Change it from “Large” or “Medium” to Full Size.
4. Save the post and check the front end.

Full Size serves the original file directly – the same one you uploaded, with all frames intact. Animation works.

The trade-off: full-size GIFs are usually large. A 1200×800 animated GIF can be 4-8MB easily. That is fine for one GIF in a post but problematic if you have a dozen on a single page.

Fix 2: Upload at the final display size#

The cleaner option for most cases. Resize the GIF in an external editor before uploading so the file is already at the dimensions your theme will display it at.

If your blog’s content area is 800px wide:

1. Open the GIF in any image editor that handles animation (Photoshop, GIMP, ezgif.com, ImageMagick).
2. Resize the canvas to 800px wide while preserving animation.
3. Save it.
4. Upload the resized version to WordPress.

When the dimensions match the display size, WordPress’s resizing pipeline still runs but the resulting “Large” version is the same dimensions as the upload, and most themes serve it as Full Size or skip resizing entirely. The animation survives.

ezgif.com is a free browser-based tool that handles the resize without you needing to install anything. It is built specifically for GIF editing – resize, crop, optimize, and convert to MP4/WebM are all single-click operations.

For batch resizing in a command-line workflow, ImageMagick’s convert -resize preserves animation if you use the -coalesce option:

convert input.gif -coalesce -resize 800x output.gif

The better alternative: MP4 or WebM video#

For most uses of animated GIFs in 2026, video is the right format. The visual result is identical, browser playback is automatic and inline, and the file size is dramatically smaller.

A 30-second animated GIF at 720p might be 15MB. The same animation as MP4 with H.264 encoding is around 1.5MB. As WebM with VP9, around 1MB. The size difference is not subtle.

How to convert

ezgif.com/gif-to-mp4 and ezgif.com/gif-to-webm handle the conversion in the browser. Or use ffmpeg locally:

ffmpeg -i input.gif -movflags faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" output.mp4

The scale filter ensures the dimensions are even numbers (H.264 requires this). The movflags faststart flag puts the metadata at the start of the file so playback can begin before the file finishes downloading.

How to embed video in WordPress so it plays like a GIF

The standard Video block plays files with controls, which is wrong for the GIF use case (you want inline auto-play, no controls, looping). To get GIF-like behavior:

1. Upload the MP4 or WebM file to the Media Library.
2. Insert a Video block in the post.
3. Pick the file you uploaded.
4. In the right sidebar, enable Autoplay, Loop, and Muted, and disable Playback controls.

Most browsers require autoplay videos to be muted (otherwise they refuse to autoplay), which is fine for a GIF replacement since the original GIF had no audio anyway. The result is a video that behaves visually like a GIF: starts on its own, loops forever, no controls cluttering the frame.

For more advanced video setups – background videos, lazy-loading, third-party embeds – how to add and embed videos in WordPress covers the broader video toolkit.

When not to use animated GIFs (or video alternatives)#

A few cases where adding an animated GIF is the wrong call regardless of format:

• Accessibility. Continuously-looping animation can trigger motion sickness in vestibular-disorder visitors and is a barrier for cognitive-disability visitors. WCAG 2.1 requires that any auto-playing animation longer than 5 seconds have a way to pause it. A looping GIF has no built-in pause, which means a strict accessibility audit will flag it. Video at least has the technical option of a pause control, even if you have hidden it.
• Performance-critical pages. A landing page measuring Largest Contentful Paint or a checkout page where every kilobyte hurts conversion is not the right place for a 5MB GIF (or even a 500KB one). Use a still image or a much shorter loop.
• Above-the-fold content. Auto-playing motion above the fold draws the eye away from the content people came to read. Save GIFs for further down the page.
• Tutorials where the still version is just as clear. “Here is what the button looks like when hovered” works fine as a static image with two frames side by side. The GIF is overkill.
• Content meant for AMP or low-bandwidth distribution. AMP has its own video and animation primitives, and animated GIFs are explicitly discouraged.

The general “is this the right time for motion” rule: if the animation conveys information that a still image cannot (a process, a transition, a result that depends on movement), use it. If it is decorative, skip it.

Common mistakes#

• Using “Large” or “Medium” size and complaining the animation is broken. WordPress is doing exactly what it always does for GIFs – the fix is Full Size or a smaller upload, not a different setting somewhere else.
• Uploading a 5MB GIF for a use case that would work as a 200KB MP4. The bandwidth and Core Web Vitals cost compounds across visitors.
• Adding 6 GIFs to a single page. Cumulatively this often loads more data than a video would, with worse playback. If you need that many animations, convert all of them to a single video file with chapters, or commit to one or two and use static images for the rest.
• Forgetting to optimize the GIF before upload. Tools like ezgif.com/optimize can cut a 4MB GIF to 800KB without visible quality loss by reducing frame count, palette, or dithering. Optimize before resizing.
• Treating GIFs as a free decorative element. Each one is an autoplay animation that affects every visitor equally regardless of device or connection. There is no version that “loads later” or “loads less” the way srcset makes a still image responsive.
• Skipping alt text. The animated nature of the image does not change the rule: every image needs alt text describing what it shows. The same conventions covered in how to add alt text to images in WordPress apply.

How Hostney handles GIF and video uploads#

GIF uploads are handled by the same image pipeline as JPGs and PNGs – GD or Imagick generates the resized versions, and the same MIME-type and upload-size limits apply. The “HTTP error” causes covered in how to add images to WordPress (PHP upload_max_filesize , memory_limit , missing image library) are the same things to check if a large animated GIF fails to upload.

For self-hosted MP4 and WebM video files served as GIF replacements, the static-asset delivery already handles the cache headers and modern HTTP versions that matter for inline-autoplay video performance. The full picture – cache, image and video optimization, render-blocking resources – is in how to speed up WordPress.

Summary#

Adding an animated GIF to WordPress is the same flow as any other image – drag-and-drop, Image block, or Media Library. The catch is that WordPress strips animation when it resizes images, so if your block displays anything other than Full Size, you get a still frame. Fix it by setting Full Size in the block sidebar, or by uploading the GIF at the exact dimensions your theme will display it at. For most uses, MP4 or WebM video is the better format anyway: identical visual result, 10x smaller, and the Video block can be configured to autoplay, loop, and hide controls so it behaves exactly like a GIF would. Reserve actual GIFs for the cases where the format matters more than the file size, optimize them aggressively before upload, and never use them above the fold.