GIF Resizer

Why I built this

I was writing documentation for a side project in January 2026 and recorded a 20-second screen capture as a 1080p GIF showing a new feature flow. The file was 38 MB — way too big for a README on GitHub (GitHub caps embedded images at 10 MB). The first three online GIF resizers I tried all uploaded my file to their servers (visible request payloads in DevTools), then displayed banner ads while I waited 90 seconds for processing. One inserted a watermark "Made with FreeGIF.com" across the bottom. Another required signup to download anything over 5 MB.

What bothered me most was that the screen recording showed internal UI of an unreleased product. The "free" GIF resizers had a copy of that proprietary screen recording sitting in their servers, retained for some unspecified period. There was no privacy policy that addressed it specifically. For documentation work, where screen recordings often contain pre-release UI, login flows, or internal data, uploading to a third party is the wrong default.

OhMyGIF resizes everything in your browser using gifuct-js for decoding and gif.js for re-encoding via a Web Worker. Your screen recording, meme reaction, or signature animation never leaves your device. Output is clean — no watermark, no metadata changes, just smaller pixels. Three rules: (1) nothing uploads, (2) no signup, (3) no watermark or metadata injection.

How it works under the hood

When you drop a GIF, the browser reads it into an ArrayBuffer using FileReader — a pure in-memory operation. gifuct-js parses the GIF structure: header, global color table, logical screen descriptor, then each frame's graphics control extension (timing, transparency flag) and image data (LZW-compressed indexed pixels). Each frame is decoded into a raw RGBA bitmap.

For each frame, we draw the bitmap onto an off-screen HTMLCanvasElement at the new target dimensions. The Canvas API uses a high-quality resampling algorithm (typically bilinear or bicubic, browser-dependent) for the scaling. The resized canvas pixel data is then fed into gif.js, which runs inside a Web Worker so the main UI thread stays responsive during the multi-second encoding process.

gif.js does the heavy lifting on the encoding side: color quantization (reducing the full RGB color space to a 256-color palette per frame using the NeuQuant neural network algorithm), dithering (Floyd-Steinberg by default to hide quantization artifacts), LZW compression, and byte-stream serialization. The result is a Blob offered as a download.

The bottleneck is encoding speed. NeuQuant in JavaScript is fast for browser code but slower than native C ffmpeg by ~3×. For a 10-second 720p GIF with 240 frames at 24fps, encoding takes 20-40 seconds on a recent laptop. Memory is the secondary constraint: decoded frame data can use 10× the original file size in RAM, which limits us to ~50 MB input files on average devices.

Verify yourself: open DevTools → Network tab, clear the log, drop a GIF, click Resize. The list stays empty — no upload, no API call. The only network activity is the initial page load, cached after first visit.

Real use cases

• GitHub README and documentation: Embed screen recordings under GitHub's 10 MB image cap. Most product demos shrink fine from 1080p to 720p.
• Slack and Discord uploads: Slack caps free tier file uploads at 1 GB total per channel; smaller individual GIFs preserve that budget. Discord caps at 8 MB per file for free users.
• Email signatures with subtle animation: Tiny animated icons (80×80, under 50 KB) for branding without slowing email clients. Most corporate mail servers strip large attachments — small is essential.
• Reaction GIF management for 가족 단톡방 or Slack: KakaoTalk has a file size limit; resize your library of reaction GIFs once, then they all upload instantly.
• Presentation slides: Embedding a GIF demo in PowerPoint or Keynote works much better when the GIF is 720p or smaller — the presentation file stays under email-friendly size.

vs other GIF tools

How OhMyGIF compares to popular GIF tools as of May 2026:

Where competitors win: Ezgif is the powerhouse of online GIF editing — they offer frame extraction, crop, rotate, change speed, change frame rate, optimize palette, and conversion to MP4/WebM. None of those are things we currently support. For heavy editing work, Ezgif is the right tool, accepting that your GIF will be uploaded. For pure resize on sensitive content, we are the better choice. Ezgif is also faster because they run libgif and ffmpeg on a server, while we run gif.js in your browser.

What this can't do

• Convert GIF to MP4 or WebM. Format conversion requires video codecs (H.264, VP9) that browsers cannot encode in real-time without WebAssembly ffmpeg, which is a 30+ MB dependency. Use Ezgif or ffmpeg CLI.
• Edit individual frames. No frame extraction, no per-frame editing. For frame-level work, use Ezgif or Photoshop.
• Change animation speed or frame rate. Original timing is preserved. Speed adjustment requires frame insertion or removal, which we have not implemented.
• Process files over 50 MB. Browser memory limit. Files over 50 MB are usually screen recordings that should be MP4 anyway.
• Optimize the palette across frames. Each frame gets its own palette. Global palette optimization (sharing colors across frames for better compression) is an advanced feature we have not added.

If you need conversion to MP4 for size (often 10× smaller than GIF), use ffmpeg locally: ffmpeg -i input.gif -movflags faststart -pix_fmt yuv420p output.mp4. For full GIF editing, Ezgif remains the most capable web tool.

Tips for best results

Resize down, never up. GIFs use indexed-color frames; upscaling reveals color banding and will not add detail. If you need a larger output, re-render the source video instead.

Pick dimensions in multiples of 2. Some downstream tools (Twitter, MP4 converters, video codecs that might re-encode your GIF) prefer even dimensions. The GIF resizer will accept any value, but choosing 600×400 over 601×401 avoids surprises later.

Consider MP4 for screen recordings over 5 seconds. Screen recordings compress 5-10× better as H.264 MP4 than as GIF. If your destination supports MP4 (GitHub does, Slack does, Discord does), use that format. GIF remains relevant only for true animations under ~5 seconds.

Lower quality = smaller file. The default quality (10) is a good balance. Increasing the number trades visual fidelity for file size. For pure-color content (logos, text animations), you can push quality lower without visible damage.

Trim before resizing if possible. A 30-second GIF clipped to 10 seconds before processing avoids decoding/encoding 20 seconds you do not need. Trimming is not a feature we offer, but Ezgif's trim tool is free and you can resize the trimmed result here for privacy.

FAQ

Will resizing make the file smaller? Usually yes — fewer pixels per frame means a smaller payload. The savings depend on the source GIF's color complexity and frame count. A 1080p GIF resized to 720p typically shrinks by 50-60%. A 720p GIF resized to 480p shrinks another 30-50%. The compression is not linear with pixel count because GIF uses LZW compression that exploits repeated patterns; simpler color palettes compress better. If your GIF has very few colors (a logo animation or text), savings can exceed 70%. If it has photographic content, expect closer to 40%.

Does the animation play at the same speed? Yes. Each frame's original delay (the per-frame timing stored in the GIF) is preserved during re-encoding. The total animation duration is identical to the input — only the pixel dimensions change. Frame count stays the same too. This matters for things like screen recordings where the original timing is meaningful, or memes where comedic timing depends on specific frame delays. We do not have a frame-rate adjustment feature; modifying frame timing requires a different tool path.

Does it work on transparent GIFs? Yes. Transparency is preserved when re-encoding. The transparent palette index from the source carries over to the output GIF, so areas that were transparent stay transparent. Note that GIF only supports binary transparency (a pixel is either fully transparent or fully opaque — no semi-transparent edges), so anti-aliased borders may look slightly different after resizing. If you need smooth transparency, consider converting to animated WebP or APNG (formats we do not yet support).

Why is the maximum file size 50 MB? Decoding a GIF expands its frames to raw RGBA in memory, which can use up to 10× the file size. A 50 MB GIF can expand to ~500 MB of working memory during processing. The 50 MB cap keeps the tool stable on average laptops and phones. Desktop browsers can technically handle more, but mobile Safari runs out of heap above this and silently crashes the tab. If you have a GIF over 50 MB, it is usually a screen recording that would be much better stored as MP4 — modern video codecs achieve 10× the compression of GIF for screen capture content.

Can I resize to a larger size? Technically yes, but the output will look blocky. GIFs use indexed-color frames (max 256 colors per frame), so upscaling reveals color banding and pixelation — there is no real detail to recover. If you need a larger output, re-render from the source video instead. Common case: someone captured a GIF from a video at 480p, then realized they need 1080p; the answer is always to re-export from the source video, not to upscale the GIF. AI-based upscaling can help for video, but GIF's palette limitations make it a poor source.

Is there a watermark on the output? No. Never. The output is a clean GIF with no branding, no attribution requirements, no hidden metadata. Many "free" GIF tools add subtle watermarks that you only notice when the GIF is shared publicly, embarrassingly revealing which sketchy site you used. We do not do that, and never will. The output is yours, period — use it for documentation, social media, marketing, memes, anywhere.

How private is GIF processing here? Fully client-side. The GIF is read into an ArrayBuffer via FileReader (in-memory only), decoded with gifuct-js into raw frame data, each frame is resized on an off-screen canvas, then re-encoded with gif.js inside a Web Worker. No network calls during processing. Verify with DevTools → Network — the list stays empty after page load. This is unusual for GIF tools because GIF encoding is computationally heavy (most competitors host the encoder to save your CPU). The trade-off is your laptop fan runs for a few seconds; the reward is your file never leaves the browser.

Why is encoding slower than I expected? GIF re-encoding is inherently slow because the format requires color-quantizing every frame to a 256-color palette. gif.js uses the NeuQuant algorithm in JavaScript, which is well-optimized but not as fast as native code. For a 10-second 720p GIF, encoding takes 20-40 seconds on a recent laptop. We use a Web Worker so the UI stays responsive during encoding. For comparison, ffmpeg on the command line is roughly 3× faster — but ffmpeg requires installing, learning command-line flags, and your file leaves nowhere because it is local already. For one-off browser use, our speed is acceptable.

Why does my resized GIF have visible color banding? GIF's 256-color palette per frame creates banding in gradients and skin tones. Resizing can worsen this because downscaling averages pixel colors, creating intermediate shades that then must be quantized back to the limited palette. The standard fix is dithering, which gif.js applies by default — small randomized pixel patterns that simulate intermediate colors. If banding is severe, consider converting to MP4 instead; H.264 has no palette limitation and handles gradients smoothly.

Why would I use this instead of Ezgif or Giphy? Ezgif is a fantastic site with more features (cropping, frame editing, conversion) but it uploads every GIF to their server. For public memes and reaction GIFs that is fine; for sensitive content (screen recordings of internal tools, personal videos) it is not. Giphy is for hosting and discovery, not really a resizing tool. Our advantage: GIFs never leave your browser. The trade-off: Ezgif offers more advanced features (extract frame, change frame rate, optimize palette) that we have not built. For pure resize, we are equivalent and more private.