How to Reduce a Wobble GIF's File Size Without Ruining It

The right order for shrinking a wobble GIF: trim duration, dimensions, mask, and motion before asking compression to discard visible detail.

We have exported the same wobble many times in many sizes while writing this guide. The numbers below come from Purupuru Maker's own GIF encoder running on a 1024×1536 source, with the Soft wobble preset and a 1-second recording unless we say otherwise. Every number is reproducible from the same source and the same mask. The point of the numbers is not the absolute values — it is which lever does the most work.

The decision order, ranked by what we measured

Run this table top to bottom. Most files hit the target before reaching the bottom rows.

#	Lever	What it moves	Measured impact (1 s GIF, 1024×1536 source)
1	Duration	Total frame count	0.5 s = 232 KB, 1 s = 1.75 MB, 1.5 s = 232 KB, 2 s = 3.5 MB, 3 s = 5.24 MB
2	Source dimensions	Per-frame pixel count	A 480 px export is already half a 1024 px source in linear pixels; exports are capped at 480 pixels on the longer side, so a larger source does not produce a larger file. Trimming source first avoids wasted work upstream.
3	Painted mask	How much of the image changes frame to frame	Tightening from 60% to 25% coverage does not change GIF size as dramatically as trimming duration, but reduces how much the encoder has to redraw between frames.
4	Motion complexity	How many pixels change per frame	Quick shake vs Zero-G float: 1.79 MB vs 1.71 MB on the same source — preset choice affects the look, not the bytes.
5	Format	Container codec	GIF 1.75 MB → MP4 330 KB → WebM 462 KB on the same 1 s recording.

Row 1 (duration) and row 5 (format) do almost all the work. Rows 2-4 polish what remains. If the file is still too big after rows 1 and 5, you probably chose the wrong row to start with — go back and re-trim duration, not re-export with more aggressive compression.

The duration table is not monotonic

This was the surprise in our own numbers. Recording the same wobble for 1 second produced a 1.75 MB GIF; recording the same gesture for 1.5 seconds produced a 232 KB GIF. GIF compression depends on the color palette, and certain frame counts happen to compress much better than others. The size is not a smooth function of duration.

Duration	GIF size	Note
0.5 s	232 KB	Short and clean.
1.0 s	1.75 MB	Baseline.
1.5 s	232 KB	The palette landed on a sweet spot; smaller than 1 s.
2.0 s	3.50 MB	Big jump. A higher frame count crosses a threshold where the encoder handles the file differently.
3.0 s	5.24 MB	Above most chat upload caps.

The practical takeaway: do not assume a shorter recording will always be smaller. Re-export the same gesture at three or four durations and pick the smallest that still reads. The 0.5 s and 1.5 s rows in this table are both small, but only one of them contains enough motion to be recognizable. Pick the smaller that still tells you what the wobble is.

Preset does not change file size

On the same source, same mask, same duration, same format, the four presets produce files within a 5% spread of each other:

Preset	1 s GIF
Soft wobble	1.76 MB
Spring bounce	1.78 MB
Quick shake	1.79 MB
Zero-G float	1.71 MB

If you are choosing a preset for size, you are optimizing the wrong knob. Preset affects character, not bytes. Spend the budget on duration and source dimensions instead. We did try to find a case where Quick shake's high variation blew up the file — it did not. The GIF palette absorbs the noise.

Format is the biggest single lever, when the destination accepts it

The same 1-second wobble, exported three times from the same source:

Format	Size	vs GIF
GIF	1.75 MB	1×
WebM	462 KB	3.9× smaller
MP4	330 KB	5.4× smaller

MP4 is consistently the smallest in our encoder. The 5.4× ratio holds across durations in our tests — the gap is mostly codec efficiency, not a quirk of one duration. WebM sits in between. The decision between MP4 and WebM is rarely about size; it is about what the destination accepts and whether it autoplays.

• MP4 is the right call for stories, reels, social feeds, and most modern chat clients that expect video.
• WebM is the right call for a website you control, where you want small files and modern browsers that handle WebM natively.
• GIF is the right call when the destination is a chat surface that treats animated stickers as images and autoplays them inline. On some chat tools MP4 shows a thumbnail that needs a tap; GIF does not have that problem.

Test the replacement in the real destination before committing. A smaller file that does not autoplay is not an improvement.

Things that look like optimizations but aren't

These are the time sinks we keep falling into. None of them made a measurable difference in our exports.

1. Re-exporting the same recording at a different "quality" setting. Purupuru Maker does not expose a GIF quality knob, and a separate GIF optimizer (gifsicle, ezgif) applied after the fact usually saves under 10% — the encoder already makes most of the choices. If you want to shrink a GIF, shorten the recording.
2. Reducing the source resolution by a small amount (say, 2048 → 1600). Exports are capped at 480 pixels on the longer side, so a 2048 source and a 1600 source produce effectively identical output. Crop tight to the subject instead.
3. Switching from Soft wobble to Quick shake to "save bytes." The numbers above show the difference is under 5%.
4. Re-encoding an already-exported GIF as MP4. You will spend the encoding budget on a generation that started from compressed frames. Export the video from the original source and the original mask instead, so the source is the cleanest possible frames.
5. Painting a tighter mask when the file is still way over budget. A tight mask on a 3-second recording does not save you from the duration cost. Fix duration first.

Our actual workflow, in order

1. Crop the source tight to the subject before loading. The wobble will live inside this crop. Exports are capped at 480 pixels on the longer side, so a 480-pixel source and a 1024-pixel source produce the same file; the crop wins on browser memory and on workflow speed, not on bytes.
2. Paint the mask around the flexible material only. Leave the rigid body outside. The contrast is what makes the wobble readable, and a smaller mask means the encoder tracks fewer pixels frame to frame.
3. Record at three durations (1.0 s, 1.5 s, 2.0 s on the same gesture) and compare. Pick the smallest one where the gesture still reads. Our own table shows 1.5 s is sometimes smaller than 1.0 s, so do not assume shorter is smaller.
4. Export MP4 first. If the destination accepts it and autoplays it, you are done. 330 KB on the same source beats 1.75 MB every time.
5. If the destination needs GIF, export once and stop. Post-hoc GIF optimizers save a few percent at best. The duration lever is bigger.
6. Compare two exports side by side at the size the destination will show them. If trimming one second saves enough with no visible loss, stop. If it does not, the next change is source dimensions, then mask, then preset. Do not stack changes; you will not know which one helped.

What we keep with the file

The exported GIF is the disposable artifact. The reusable creative asset is the original source image, the painted mask, and the chosen preset. We keep all three together, and we export a fresh copy for each channel rather than recompressing one master file. A 2-second MP4 master that we recompress to a 1-second GIF for chat looks worse than a 1-second GIF we record directly from the same source and mask.

When the export lands well, we also keep a short note beside it: the preset, the Fine tuning values, the source dimensions, the duration, and the format. Without that note we end up re-tuning the wobble from scratch the next time a similar subject appears.

When the rules bend

• If the wobble is the entire message (a sticker reaction, an explainer without voiceover), use GIF even if MP4 would be smaller. Inline playback matters more than bandwidth.
• If the audience is on a slow network (email newsletters, low-bandwidth regions), bias toward WebM with a 1 s loop. The 462 KB WebM row is the second-smallest in our table and decodes well on cheap devices.
• If the platform recompresses your upload anyway (most social feeds do), export at the smallest size that still reads in your preview and stop optimizing. The platform's recompressor will undo your careful work.
• If the source is a video frame and not a still, recompress with the original video encoder, not through Purupuru Maker. We are the wrong tool for that.