To include a GIF in a WordPress post
GIFs show up everywhere in blog posts now, from step-by-step tutorial screenshots that move to reaction images breaking up long paragraphs of text. Adding one to a WordPress post is mechanically simple. The part that actually trips people up is everything around that step: file size, where the GIF comes from, whether it slows the page down, and whether it plays nicely with mobile visitors on a spotty connection. None of that is complicated once you know where to look, but it’s rarely covered in the same breath as the basic upload instructions, which is usually why people end up with a working GIF and a noticeably slower page at the same time.
You can follow these steps to add a GIF you already have saved
1. Find a GIF you want to use and save it to your computer.
2. Log in to your WordPress dashboard.
3. Click on “Posts” in the left-hand menu and select “Add New” to create a new post.
4. In the block editor, click the “+” icon to add a new block and choose the Image block, or click on the “Add Media” button if you’re still using the Classic editor.
5. Drag and drop the GIF file into the block, or click “Upload” to select the file from your computer.
6. Once uploaded, the GIF appears directly in the editor. It will animate in the editor preview the same way it will on the live page.
7. Preview or publish the post to confirm it plays correctly.
Note: Some WordPress themes crop or resize images in ways that can interfere with how a GIF displays, so it’s worth previewing the post in the actual theme before publishing rather than trusting the editor preview alone.
Adjusting the GIF After It’s Inserted
Once the GIF block is in place, click on it to reveal the block toolbar and the settings panel on the right side of the editor. From there you can adjust the image’s dimensions directly, or use one of the preset sizes (thumbnail, medium, large, or full size) if you’d rather not resize manually. Dragging the corner handles works for a rough resize, but typing exact pixel values into the width and height fields in the block sidebar gives more control, especially if the GIF needs to match the width of surrounding text or other images on the page.
To add a caption, click directly below the GIF where WordPress shows a “Write caption…” prompt, and type the text there. The caption will appear beneath the GIF once published, in whatever style the theme applies to image captions. To link the GIF to a URL, either an external site or another page on your own site, select the block, click the link icon in the toolbar, and enter the destination URL.
Embedding a GIF from Giphy or Tenor instead of uploading a file
Not every GIF needs to live on your own server. Giphy and Tenor both let you grab a direct embed link or an .mp4/.gif URL for any GIF in their library, which you can paste directly into an Image block in the same way you’d add an uploaded file, using the block’s URL option instead of Upload. This skips the step of downloading and re-uploading the file, though it does mean the GIF is now hosted on Giphy’s or Tenor’s servers rather than your own, so if that GIF ever gets removed from their platform, it disappears from your post too.
File Size: The Part Everyone Forgets
This is where most GIF-related page speed problems come from. A short, low-resolution GIF might weigh 500KB. A longer one, or one captured at a high resolution, can easily hit 5MB or more, because GIF is an old, relatively inefficient format that doesn’t compress motion the way modern video codecs do. A single 5MB GIF sitting at the top of a blog post can do more damage to page load time than every other image on the page combined.
A few practical fixes help here. Tools like EZGIF let you compress an existing GIF, trim its length, or reduce its resolution before uploading, often cutting file size by half or more with barely noticeable quality loss. Keeping the GIF short, two to five seconds is usually enough to make a point, matters more than almost any other factor in keeping the file size reasonable. Cropping the GIF to only the relevant part of the screen, rather than capturing an entire browser window, also helps considerably.
Should It Even Be a GIF? The Case for Converting to Video
For anything longer than a few seconds, or anything showing a multi-step process, a short muted MP4 or WebM video, uploaded through the Video block instead of the Image block, is almost always the better technical choice. Video codecs handle motion far more efficiently than GIF, so the same clip that’s 4MB as a GIF might be 400KB as a compressed MP4, a tenth of the size for visually identical results. The tradeoff is that video requires the visitor’s browser to render a video player rather than a static image, and autoplay behavior varies slightly across browsers, so testing on both desktop and mobile before publishing is worth the extra few minutes.
WordPress also supports animated WebP as a middle ground: smaller than GIF in most cases, still displays as a simple animated image without a player interface, though older browsers have spottier support for it than for GIF or standard video.
The rough numbers make the case clearly enough. A five-second screen recording exported as a GIF at reasonable quality often lands somewhere around 3MB to 6MB. The same clip exported as a compressed MP4 typically comes in under 500KB, sometimes closer to 200KB depending on how much motion is actually happening on screen. That’s roughly a tenfold difference for content that looks nearly identical to the visitor. On a site that publishes a handful of tutorial posts a month, sticking with GIF by default rather than converting to video adds up to real, measurable bandwidth cost over a year, and on mobile connections it adds up to real, measurable waiting time for visitors too.
Accessibility and Motion Sensitivity
Animated GIFs that loop continuously can be genuinely uncomfortable or disorienting for visitors with vestibular disorders or certain forms of photosensitivity, and this is worth taking seriously rather than treating as an edge case. Always fill in the alt text field for a GIF the same way you would for a static image, describing what it shows, since screen readers rely entirely on that text and can’t interpret motion. For GIFs that aren’t essential to understanding the content, consider whether a static image with a “click to play” link to the animated version might serve visitors better than an animation that starts moving the instant the page loads and never stops.
Creating a GIF From a Screen Recording
Most tutorial GIFs don’t start life as GIFs at all. They start as a short screen recording that then gets converted, and getting this part right avoids a lot of the file size headaches described earlier.
On a Mac, QuickTime Player’s screen recording feature (File > New Screen Recording) captures a clean video of a specific screen region. That video can then be dragged into a converter like EZGIF’s video-to-GIF tool, which lets you trim the clip, set the output frame rate, and resize before exporting, all of which directly affect the final file size. Lowering the frame rate to 10 or 12 frames per second, rather than the 30 or 60 the original recording captured, cuts file size substantially with almost no visible difference for typical UI demonstrations, since screen interactions rarely need smooth high-frame-rate motion to be understood.
On Windows, the built-in Xbox Game Bar (Windows key + G) or ScreenToGif, a free dedicated tool built specifically for this purpose, both handle the recording and conversion in one step, skipping the separate video-to-GIF conversion entirely. ScreenToGif in particular gives frame-by-frame editing control, useful for trimming a recording down to exactly the moment that matters rather than including a few extra seconds of dead time at the start or end.
Whichever tool is used, the same principle applies: record only the specific region of the screen relevant to the tutorial, and keep the clip as short as the point being made actually requires. Reducing the frame rate before exporting matters too. Doing this work at the recording stage, instead of trying to compress an already-bloated GIF afterward, produces a noticeably smaller file with less quality loss than compressing after the fact.
GIFs in Email Digests and RSS Feeds
A GIF that works fine on the live page can behave unpredictably once the post gets pulled into an email newsletter or RSS reader. Many email clients, particularly older versions of Outlook, either show only the first frame of a GIF or block animated images entirely by default, which means visitors reading a post through a newsletter service like Mailchimp or Groundhogg might see a static, sometimes awkward, first frame instead of the intended animation. If the first frame of a GIF looks confusing or meaningless on its own, it’s worth choosing a starting frame that still communicates something on its own, in case that’s the only frame some readers ever see.
RSS feed readers vary similarly. Some render animated GIFs exactly as uploaded, while others strip animation for performance reasons on their own end, especially in feed reader mobile apps that prioritize fast scrolling over fully rendering every image. There’s no universal fix for this beyond picking a first frame that holds up as a still image, since the animation itself is largely outside your control once the content leaves your own site.
Common Mistakes When Adding GIFs to Posts
Uploading the GIF at a far larger resolution than it will ever display is the most frequent mistake. A GIF captured at 1920 pixels wide but shown in a 700-pixel-wide content column is still downloading the full 1920-pixel file to the visitor’s browser, then scaling it down visually, which wastes bandwidth for no visual benefit. Resizing the source file down to roughly the display width before uploading avoids this entirely.
Stacking multiple GIFs in the same post is another common issue. Each animated GIF keeps running continuously once loaded, and a browser rendering three or four looping animations at once on a single page can noticeably tax older phones and laptops, sometimes causing visible scroll lag. Limiting a single post to one or two GIFs, and using static screenshots for the rest, usually strikes a better balance between visual interest and page performance.
Forgetting to check how the GIF looks on a narrow mobile screen is the third common miss. A GIF cropped to highlight a specific part of a desktop browser window can end up illegible once squeezed down to a 375-pixel-wide phone screen. Previewing the post on an actual phone, not just the browser’s device-simulation mode, catches this reliably.
Frequently Asked Questions
Why did my GIF stop animating after I uploaded it to WordPress?
This usually happens when an image optimization plugin recompresses the file on upload and accidentally strips the animation frames, treating it like a static image. Checking the optimization plugin’s settings for an “exclude GIFs” or “skip animated images” option usually fixes it. If the plugin doesn’t offer that option, excluding the specific GIF from optimization manually is the next best step.
Is there a maximum GIF file size WordPress will accept?
WordPress itself doesn’t impose a GIF-specific limit, but your hosting provider’s PHP upload limit (commonly 2MB to 64MB depending on the host) applies to any file type, GIFs included. A GIF that large would also badly hurt page speed regardless of whether the upload succeeds, so compressing it down first is worth doing either way.
Can I use a GIF as the featured image for a post?
Technically WordPress allows it, but featured images are almost always displayed at a fixed, often smaller size in archive listings and social sharing previews, both of which typically strip the animation and show only the first frame. A GIF used as a featured image usually just becomes a static image in most contexts, so there’s rarely a good reason to use one there instead of a properly optimized static image.
Do GIFs slow down mobile pages more than desktop?
Generally yes, since mobile connections are more likely to be slower or metered, and the GIF still has to fully download before it can play regardless of screen size. This is another reason to lean toward compressed video over GIF for anything longer than a couple of seconds, particularly on sites where a meaningful share of traffic comes from mobile visitors.
Should a GIF lazy-load the same way images do?
Yes, and most modern WordPress themes and the core lazy-loading feature introduced in WordPress 5.5 apply the same loading="lazy" attribute to GIFs as they do to any other image, deferring the load until the visitor scrolls near it. This helps initial page load time for posts with a GIF further down the page, though the GIF above the fold, the one visible without scrolling, generally shouldn’t be lazy-loaded, since delaying it can actually cause a visible flash or layout shift as the page finishes loading.
Can I loop a GIF only once instead of infinitely?
The GIF format itself supports a loop count baked directly into the file, and most GIF editing tools, including EZGIF, let you set the number of loops (or “play once”) before export. This isn’t something WordPress controls after upload. If a GIF needs to play once and then stop on a specific frame, that setting has to be applied in the editing tool before the file is uploaded to the media library.
Is it better to host GIFs myself or embed them from Giphy?
For GIFs that are part of the actual content, screenshots, tutorials, product demos, hosting them yourself is usually the safer long-term choice, since an embedded Giphy or Tenor GIF can be deleted or changed on their end without warning, breaking the post. For purely decorative reaction GIFs where losing the image later wouldn’t matter much, embedding saves storage space on your own server and is a reasonable tradeoff.
Will a large GIF hurt my Core Web Vitals score?
Yes, and it usually shows up in the Largest Contentful Paint metric if the GIF sits near the top of the post, since the browser has to finish downloading the full file before that portion of the page is considered visually complete. A GIF further down the page, loaded lazily, has less impact on that particular score but still adds to overall page weight and data usage. Running the post through PageSpeed Insights after publishing is the simplest way to confirm whether a specific GIF is actually causing a measurable problem rather than guessing.
None of this means GIFs should be avoided. A well-chosen, properly compressed GIF still communicates a quick UI interaction faster than several static screenshots stacked with arrows and captions ever could. The goal is just picking the format and the compression settings on purpose, instead of uploading whatever file came out of the screen recorder and hoping the page still loads quickly.