One upload, several copies, and only the original moves
Upload an image to WordPress and it stores a set, not a file: the original plus thumbnail, medium, large, and any sizes your theme registers. For a JPEG that's housekeeping. For an animated GIF it's where the motion dies: on the server, the ImageMagick editor jumps to the first frame before it resizes anything, and the GD fallback can't write a multi-frame GIF at all. Core admits it in its own source: "WordPress flattens animated GIFs into one frame when generating intermediate sizes."
So in the Image block, open Settings and set Resolution to Full Size. Large, Medium, and Thumbnail are stills of frame one, and featured image slots usually request one of those, so a GIF featured image usually sits frozen.
One 4K trap: over 2560 pixels on a side, WordPress resizes a copy, serves that as Full Size, and a resized GIF is frozen. Stay under 2560.
No srcset for a GIF, so a phone downloads the desktop file
Every other image on your site gets a srcset, a menu of sizes so a phone pulls a small copy. Core refuses to build one for a full-size GIF, because the alternates would be frozen. Everyone gets the original. It's the one image your site can't serve smaller to a small screen: the width you export is the bytes every reader downloads, on cellular.
The export settings do the rest:
- Width matches the column. Most themes run a content column of roughly 600 to 800 pixels, so a 1920-pixel capture pays for pixels nobody sees. Crop to the interaction (16:9 around a panel, 1:1 around one control), then downscale.
- Ten to fifteen fps, 64 to 128 colors. Cursors and menus read fine at 12, and interface chrome is flat fills; climb only when a gradient bands.
- Extra Compression. Medium usually lands 30 to 50 percent smaller for mild grain, on top of the always-on optimizer that merges identical frames.
Watch the estimate and stop under about 1 MB, or 500 KB if the GIF is the hero. An existing GIF shrinks the same way.
Placement decides whether the browser fetches it first or last
WordPress has spent several releases teaching browsers which image to load first, and a GIF lands on one side of that logic or the other. Since 5.5, images get loading="lazy" by default. Since 5.9, the first content image is exempt. Since 6.3, that first image, if it covers more than 50,000 square pixels (past roughly 224 by 224), also gets fetchpriority="high": fetch this ahead of everything else.
Put a 6 MB GIF first and you've nominated it as the page's top-priority download and its likely Largest Contentful Paint. Three paragraphs down, the same file lazy-loads while the reader is still on the intro. So decide: a loop that decorates goes below a still or a paragraph; a loop that is the point goes on top and gets the 500 KB budget.
Your host set the upload cap; WordPress just reads it aloud
Self-hosted, the ceiling isn't a WordPress setting. It's the smaller of two PHP values, upload_max_filesize and post_max_size, which PHP ships at 2 MB and 8 MB. Most hosts raise both, and WordPress prints the result at the bottom of Media, Add New, credited to your hosting provider. Read that line before you fight an upload error.
WordPress.com flips it: as of this writing, files up to 2 GB upload reliably, but the plan quota is the real wall, roughly 1 GB on Free, 6 on Personal, 13 on Premium, 50 on Business and Commerce. Either way, the number that should scare you is the reader's, not the host's.
WordPress 7.1 converts your GIF to video, which tells you something
WordPress 7.1, out since August 2026, moved image processing into the browser and took a position on GIFs. Upload an opaque animated GIF from the block editor in Chrome or Edge 137 or newer, over HTTPS, and the editor decodes it frame by frame and encodes a companion MP4 or WebM. The attachment stays a GIF, and the post keeps showing it until you take the toolbar's offer to display it as video, a reversible swap to a Video block that autoplays, loops, and stays muted. Firefox and Safari fall back to the server and get no conversion. Long GIFs mean a long spinner, and past a default budget of roughly 300 megapixels of decoded frames (1080p at 30 fps spends that in under five seconds) the editor won't start the conversion at all.
Core is agreeing with Google here. web.dev's reference example takes a 3.7 MB GIF to 551 KB as MP4, and Lighthouse has an audit named Use video formats for animated content. With the source clip in hand, skip the round trip: flip Output Format to MP4 in the same editor (physics on the GIF to MP4 page) and drop it in a Video block with Autoplay, Loop, Muted, and Play inline on. Leave Playback controls on; the GIF variation hides them, an accessibility complaint that already has the variation slated for removal from Gutenberg.
The GIF still wins three places: subscriber email, where WordPress.com's newsletter can send the full post and a video tag mostly won't play (classic Outlook freezes frame one, per the email guide); featured images, which are image-only; and readers on pre-7.1 sites. Whichever you pick, the trim, crop, and encode finish before your browser says a word to any server; the first machine that ever holds the file is the one you already pay for.