Resize GIF

Change an animated GIF's dimensions by typing exact pixels or a percentage, without losing the animation.

1. 1

   Add your GIF

   Drag an animated GIF onto the drop area, or click to browse. Animated WebP and APNG work too. The file is read on your device and never uploaded.

2. 2

   Set the size

   Type a width, a height, or both — with the aspect lock on, filling in one fills in the other. A percentage works too, and going above 100% enlarges rather than being ignored.

3. 3

   Choose how a different shape is handled

   If your target box has different proportions from the source, pick fit, stretch, crop or pad. Fit is the safe default: nothing is distorted and nothing is cut off.

4. 4

   Download the resized GIF

   Press Download. Each frame's delay, the loop count and any transparency come through unchanged, so the animation plays exactly as it did.

A GIF arrives at whatever size it was made, and that size is rarely the size you need. A screen recording captured at 1920 pixels wide is unusable as an email attachment and illegible as a 128-pixel emoji. A reaction GIF pulled from a phone is 480 wide when the documentation column is 700. And unlike a photograph, you cannot simply let the browser scale it: a GIF displayed smaller than its natural size still downloads every one of its full-size pixels, so the reader pays for resolution they never see.

Type exact dimensions or a percentage, enlarge as well as shrink, and switch to Pixel mode to keep sprite edges crisp.

Reads GIF, animated WebP and APNG. Writes a standard GIF89a with per-frame delays, loop count and transparency preserved.

What changing the dimensions actually buys

• Bytes, in quantity. Halving the width and the height removes roughly three quarters of the pixel data. It is the single cheapest size reduction available, because it costs nothing about the motion.
• A slot that fits. Emoji slots, avatar frames and documentation columns are fixed widths. Something that does not fit is either cropped by someone else's rules or scaled by someone else's algorithm.
• Legibility. Text inside a screen recording is either readable at the display size or it is decoration. Resizing deliberately is how you find out before publishing.
• Sprites that stay sharp. Pixel art enlarged with smoothing is ruined and cannot be recovered. Enlarged with nearest-neighbour it is perfect at any whole multiple.

A still image has one raster. An animated GIF has a stack of them, each potentially covering only part of the canvas, each with its own delay, its own palette and its own transparency mask. Resizing one correctly means compositing every frame onto the full canvas first, scaling that, and then rebuilding a palette across the whole animation rather than per frame. Tools that skip the compositing step produce output that jumps, because a frame that was legally a 30-pixel patch at an offset gets scaled as though it were the whole picture.

What happens to each frame

• Composite. Every frame is drawn onto a canvas of the animation's logical size, honouring its offset, its disposal method and its transparency, so what gets scaled is the picture a viewer would actually see.
• Scale. One draw per frame at the target size, on your graphics hardware where it is available. Smoothing on for photographic material, off for pixel art.
• Re-quantise. A palette is built from a sample spread across the whole animation, not from the first frame, then every pixel is mapped to it.
• Re-optimise. Unchanged regions between frames are marked transparent again at the new size, which is where most of the file size goes.

What a resizer must not change

Three things have to come out exactly as they went in: each frame's own delay, the loop count, and which pixels are transparent. A tool that re-times an animation while resizing it produces a perfectly valid GIF that simply plays at the wrong speed, and one that flattens transparency produces a picture with a white box around it. Both are checked here on every run rather than assumed.

Every resizer smooths by default, and for photographs that is correct — interpolating between neighbouring pixels is what stops a scaled photo looking like a mosaic. For pixel art it is destructive in a way nothing can reverse. A 1-pixel black outline on a sprite, enlarged four times with smoothing, becomes a four-pixel grey gradient; the crisp edge is gone and no amount of sharpening brings it back. Nearest-neighbour simply repeats each source pixel, so a 4× enlargement turns every pixel into a clean 4×4 block. Measured on this tool's own test sprite scaled 64 to 256: smoothing produced 94 distinct colours along the middle row, nearest-neighbour produced exactly 8 — the number the source actually contains.

Measured results

• Nearest-neighbour vs smoothing 8 distinct colours across a row against 94, on a source containing 8. The mode is the difference between preserving the art and averaging it away.
• Resample accuracy Smooth mode differs from libvips's lanczos3 by 3.31/255 mean across the frame — two independent implementations agreeing.
• Transparent vs coloured padding 49,167 B against 13,961 B for the same picture. Transparent padding costs the frame-to-frame optimisation, which is worth 3.5× here.
• Speed 100 frames from 480×270 to 960×540 in 1,149 ms; the same clip down to 240×135 in 112 ms.

The most common mistake is resizing to a number that sounds tidy rather than one the destination uses. Before typing anything, find out what the target actually renders at — a documentation column, an emoji slot, a chat client's inline width — and match it exactly. Resizing to 500 when the column is 700 means the browser scales it back up and undoes the work; resizing to 1400 for a 700-pixel column doubles the download for a difference only a high-density screen can show, and even then only if the source had the detail to begin with.

By material

• Screen recordings with text. Do not go below the size at which the text is readable — check the preview, not the number. Smoothing is right here; the text is anti-aliased already.
• Pixel art and sprites. Switch to Pixel and use whole multiples: 2×, 3×, 4×. A non-integer scale of pixel art produces uneven block sizes even with nearest-neighbour, because some source pixels land on two output pixels and some on three.
• Video-derived footage. Smoothing, and shrink rather than enlarge. Enlarging video-derived frames exposes the compression artefacts that were invisible at the original size.
• Anything going into a fixed square. Crop, not Pad. A padded square has visible empty bands; a cropped one fills the slot the way every other image in it does.

• Custom emoji. Discord and Slack both take 128×128, and both reject anything much over 256 KB — so this and the compressor are usually used together.
• Documentation and READMEs. Match the rendered column width exactly so the browser does no scaling of its own.
• Email signatures. Small dimensions are the only reliable way to get an animation under the size most mail servers accept.
• Avatars and profile images. Square, cropped, and small enough to load before the page finishes rendering.

Sizes worth memorising

Discord and Slack custom emoji are 128×128. X renders inline images up to 506 pixels wide. GitHub's README column is 768 at full width and roughly 700 in practice. Most documentation themes sit between 680 and 760. Anything wider than the column it lands in is bytes the reader downloads and never sees.

The input list is closed and enforced at the file dialog rather than at the engine, so a file this tool cannot open is refused in milliseconds with a route to the tool that can — instead of being accepted and failing later behind a spinner.

• GIF in. Animated or single-frame, interlaced or not, with a global palette or a different local palette on every frame. Sub-rectangle frames at an offset are composited onto the full canvas before anything is scaled.
• Animated WebP and APNG in. Both are read by our own demuxers on every browser rather than by a native decoder, so frames and timing are identical everywhere.
• GIF out, always. A standard GIF89a with a global colour table, per-frame delays, disposal methods and a Netscape loop extension.
• Anything else is refused with a route. A video is sent to Video to GIF, a still image to the GIF Maker.

What the tool reads

GIF is decoded natively where the browser has a decoder for it and by our own reader everywhere else, so an animation opens the same way in every browser rather than arriving as its first frame. Animated WebP and APNG always take our own reader, which is what keeps frame counts and timing identical across engines.

Size and batch limits

• Free. One file up to 50 MB and up to 300 frames, output up to 2048 pixels on the long edge. Full quality — the free plan is not a reduced-quality resize, it is a single-file one.
• Pro. Up to 20 files at once, downloaded as one ZIP, with no imposed dimension cap. Batch is what Pro buys here, because resizing a set of emoji or a folder of documentation clips one at a time is the actual chore.
• The limit both plans share. Every frame is expanded to full colour while it is being worked on, so a memory budget bounds the job before it starts rather than letting the tab stop responding while the progress ring keeps turning.

Nothing is uploaded. The file is decoded frame by frame on your machine, each frame is composited and scaled, a palette is built across the whole animation, unchanged regions are marked transparent again, and the result is written out as a standard GIF89a. All of it runs in a background thread so the page stays responsive, and the scaling itself runs on your graphics hardware where it is available.

Why the same file resizes identically every time

• A deterministic quantiser. Median cut, not the randomised neural quantiser most GIF libraries use, so the same input with the same settings always produces byte-identical output.
• Identical results on every path. The graphics-accelerated and processor paths are required to produce the same bytes, not merely similar ones — a path choosing a different palette entry would show as colour flicker between frames.
• Geometry checked against another implementation. The smooth resample is verified against libvips, a completely separate image library, rather than against our own previous output.

Scaling is hardware accelerated where your device supports it, and the accelerated and fallback paths are verified to produce byte-identical output. The smooth resample is checked against an independent image library. Measured on the reference device: 100 frames from 480×270 to 960×540 in 1,149 ms. It all runs on your device, not our servers.

• GIF Compressor
• GIF Maker
• Video to GIF
• GIF to MP4
• GIF Editor
• All GIF tools