Reframing a screen recording without flattening it to one frame
A GIF is not a picture. It is a stack of frames, a color table and a loop flag, and that is precisely why so many “crop” buttons betray it: point a still-image editor at an animated GIF and you frequently get the first frame back with everything after it discarded.
This page exists for the opposite case, where the motion is the entire point. A screen recording that carries a strip of taskbar along the bottom. A wide reaction clip that would make a much better avatar if it were tight on the face. A tutorial capture with a logo sitting in one corner. All of those want the same operation: keep a smaller rectangle, keep every frame, keep the loop.
Even on this site, the neighboring image cropper is not the answer. Its accepted extension list runs .jpg, .jpeg, .png and .webp, so a .gif is rejected before its processing step ever starts, with a message naming the formats it does take. That refusal is honest, and it is the reason this separate GIF page exists at all.
Dragging the box, then reading the selection line beneath it
The first frame is decoded with the browser’s own image decoder, which hands back exactly one frame from a multi-frame GIF without any help from FFmpeg. That frame is drawn onto a preview canvas capped at 420 pixels on its longest edge, with an SVG overlay on top carrying the selection rectangle and four round corner handles.
Under the stage sits a line that reads “Selection”, then a width and height in pixels, then the offset, then the GIF’s real dimensions for comparison. Those are not preview numbers. They are the values that come out of the same scale-then-clamp function the crop step itself runs, so the line is a live preview of the arguments FFmpeg is about to receive.
One rough edge worth knowing: when the preview is a scaled-down copy of a larger GIF, the horizontal and vertical offsets are not forced onto whole numbers, so the offset in that line can arrive with a long decimal tail. The width and height beside it are always whole, and always even.
Cropping a 400 by 300 GIF, start to finish
- Use the Upload a GIF to crop file picker. The first frame appears with a centered selection box already on it.
- Drag the box body to move it, or a corner handle to resize it. On a 400 by 300 GIF, which is small enough to be previewed at full size, the default box lands as 280 by 210 pixels at offset 60, 45.
- Check the Selection line under the preview until the numbers read the way you want them.
- Click Crop GIF. A progress percentage appears alongside a Cancel button.
- The download starts on its own when the crop finishes. A Download link with the file’s size next to it also stays on screen afterwards, in case your browser blocked the automatic one, and the name gains a
-croppedsuffix. - Use Choose another GIF to clear the stage and start again with a different file.
Even widths, and the pixels the clamp may take back
Before anything reaches the filter graph, the rectangle passes through a clamp that does three jobs in a fixed order. It pulls the offset back inside the image, then caps the size to whatever room is left from that offset, then rounds the width and height to the nearest even value. Rounding up is preferred, but when rounding up would overshoot the space available it rounds down, so a selection covering an entire 299-pixel-wide frame comes out as 298.
The same clamp runs twice. The widget applies it while you drag, against the preview canvas’s own dimensions, so the box can never be pushed off the stage in the first place, and the scale back up to the GIF’s real pixels happens afterwards. Then the processing step runs a bare probe pass, reads the resolution out of FFmpeg’s own stream dump, and clamps a second time against that. If the probe cannot find a resolution in the log, the crop stops with a message saying it could not read the GIF’s dimensions, and this page shows you that message rather than a generic apology.
The palette pass, and what a crop costs in color
GIF stores at most 256 colors per palette, which is why every GIF encode on this site uses a two-pass approach: one pass builds a palette from the frames, a second maps the frames onto it. The filter graph here puts crop first in the chain, before the split into palette-generation and palette-application branches. That ordering matters. The palette is computed only from the pixels that survive your crop, so those 256 slots are spent on the region you kept instead of being partly wasted on the border you threw away. The loop flag is written as loop-forever.
Be clear-eyed about the cost, though. Changing every frame’s dimensions means a genuine re-encode, and a regenerated palette is not the source palette. Colors can shift, and dithering patterns can change. This is not a lossless trim. If you are chasing file size rather than framing, Compress GIF targets that directly, and GIF Speed Changer rescales each frame’s presentation timestamp instead of touching frame dimensions at all.
When crop-video or a format change is the better page
Reach for Crop Video when the source is an .mp4, .mov, .m4v or .webm. It works differently on purpose: instead of a free-form box, it takes an aspect-ratio choice and computes the largest centered rectangle at that ratio, defaulting to vertical 9:16 for short-form platforms.
If the GIF is going somewhere that accepts video, converting is usually the better trade than cropping. GIF to MP4 escapes the 256-color ceiling entirely, and MP4 to GIF is the route back. The rest of the collection lives on the video tools hub.