Why a GIF needs its own resizer
A general image resizer will not do this job, which is why a dedicated gif resizer exists at all.
Open an animated GIF in most image editors and you get its first frame. Scale it, save it, and the animation is gone. That is not a bug in those tools; they are built around a single raster image, and a GIF is a sequence with its own timing attached.
Being able to resize a GIF properly means scaling every frame, keeping the delay between them, and writing them back as one looping file. That is what this page does, and it is the entire reason it exists as something separate from the ordinary image resizer.
The palette problem nobody mentions
Each frame of a GIF is an indexed image: the pixels are not colours but numbers pointing into a table of at most 256 entries. When you resample that image, the interpolation between two neighbouring pixels produces a colour that sits between their two palette entries, and that colour has nowhere to go.
The fix is to rebuild the palette from the scaled frames rather than reusing the original. That is why a colour control appears on a resize tool, which looks odd until you know why. Leave it at the default and the result tracks the source closely; drop it to 64 or 32 when you want the file smaller and the content is flat graphics rather than photographic.
Picking a width
GIF file size follows the pixel count closely, so width is the strongest lever you have. Halving it cuts the area to a quarter and typically takes the file down by a similar factor. For a chat message or a documentation page, 480 pixels is usually plenty; 320 is fine for an inline example; 800 is worth it only when fine detail actually matters.
None of this is guesswork you have to do twice: to resize an animated gif here, pick a width, look at the result playing in the page, and change it if it is wrong.
Everything runs in your browser. Files up to 500 MB are accepted, nothing is sent to a server, and the engine is fetched once on first use and cached afterwards.