ShareX screen recordings can produce animated GIFs whose pixel dimensions or file size exceed upload limits, embed limits, or display requirements, and the fastest way to shrink a ShareX GIF that is too large is to resize its canvas proportionally in your browser with GIF Resizer. ShareX captures frames by screenshotting the screen at the chosen frame rate and quality, so a 1080p or 1440p monitor at 10 FPS quickly lands in the tens of megabytes for just a few seconds of footage. The output is a perfectly valid GIF, but the canvas is simply larger than the place it needs to go. Resizing the canvas proportionally keeps the aspect ratio intact while cutting the pixel count, and a smaller canvas usually produces a smaller GIF once the animation is re-encoded. Because ShareX stores each GIF on disk after capture, you can open the same file in a local browser tool without re-recording and without uploading anything.
Why ShareX GIFs end up too large
ShareX is a full-screen capture and recording tool, and its GIF recorder works by taking a screenshot at a chosen FPS and stitching the frames into an animated GIF. By default, every frame is the full size of the selected capture region at your monitor's native resolution. A 2560-by-1440 capture region at 10 FPS produces around 3.6 million pixels per frame, and GIF encodes each frame against a palette of up to 256 colors, so the file size climbs fast even when the motion is simple. The result is a GIF that plays correctly but weighs well past what many destinations accept. Chat platforms, email providers, and CMS forms commonly cap uploads at a few megabytes, and several chat apps enforce strict pixel caps on inline previews.
When the destination cares about pixel dimensions rather than file size, the same recording can also be too tall or too wide. A large-canvas GIF displayed inside a narrow chat preview looks correct but wastes pixels and bandwidth on every load. Lowering the capture size in ShareX helps for the next recording, but it does nothing for the GIF already saved on your disk.
What GIF Resizer does to a too-large GIF
GIF Resizer is a browser tool that takes one animated GIF and outputs a proportionally smaller version with the same visible frames and frame delays. The original file is decoded in the current browser tab, every visible frame is composited onto a full canvas according to the GIF's disposal instructions, the full canvas is scaled to your requested width, and the result is re-encoded as a fresh GIF and offered as a single download. Nothing leaves your device during this process: the source file, the decoded pixels, and the resulting Blob stay local unless you save the new file yourself.
Because the page composites each frame before resizing, the output represents what a viewer should actually see at each frame boundary rather than the raw patches the original encoder stored. That distinction matters: many GIFs store a first image plus small patches that only update part of the canvas, and each patch can carry a disposal instruction that affects what the next frame shows. Treating each patch as a complete picture and resizing it independently can leave missing backgrounds, transparent holes, or smeared trails. Compositing first, then resizing, avoids those artifacts.
Width is the only geometry control. The page reads the source canvas ratio from the GIF header and uses your entered width to calculate the output height in whole pixels. There is no option to crop, pad, stretch one axis independently, rotate the animation, change frame order, or pick a new aspect ratio. If any of those changes are part of the plan, they need to happen before resizing.
How to resize a ShareX GIF that is too large
The fix is a three-step browser workflow. The whole process runs locally, so the ShareX file never leaves the device.
- Choose the animated GIF that ShareX saved on your disk. The page accepts one GIF up to 20 MB and reads its logical canvas dimensions. Confirm the detected source canvas shown on the page matches what you recorded: a 1920-by-1080 monitor capture should report 1920 by 1080, and a custom region should report its own width and height. If the detected canvas looks wrong, the recording is damaged or the wrong file is selected.
- Enter the target width in whole pixels. Width is the only geometry input. Pick the width that matches your destination: narrower values for chat previews, mid-range for documentation embeds, and larger sizes for blog illustrations. The page calculates the matching height from the source ratio and rounds it to a whole pixel, so a 1920-by-1080 source entered at 480 produces a 480-by-270 output.
- Select Resize GIF, then download and review the result. The page decodes the animation, composites each frame, scales the visible canvas, and encodes a new GIF locally. A download link appears once the new file is ready. Save it to disk and open the result in your browser or the target application. Watch the first full cycle at the intended display size and check timing, text legibility, and edge quality.
ShareX recording tweaks that reduce GIF size at the source
Resizing the saved GIF is the right fix for what is already on disk, and a few ShareX settings can also keep the next recording from coming out too large in the first place. The table below summarizes the directional effect of each setting on the output file.
| ShareX setting | Direction of effect on output GIF size |
|---|---|
| Capture region dimensions | Larger region produces more pixels per frame and a larger GIF; a smaller region produces fewer pixels per frame and a smaller GIF. |
| Capture frame rate (FPS) | Higher FPS adds more frames to the animation and increases the file; lower FPS removes frames and shrinks it. |
| GIF encoder quality | Higher quality preserves fine detail and increases the file; lower quality discards detail and reduces it. |
| Output format choice | MP4 captures the same motion at a much smaller file than GIF; pick GIF only when a GIF is actually required. |
For captures that are already saved, resizing is the change that actually fits the destination, and quality or frame-rate tweaks would mean re-recording from scratch.
What gets changed and what gets preserved
Understanding exactly what the tool changes helps set the right expectations for the output.
Preserved: the decoded visible frame order, and each frame's decoded delay that controls how long a frame stays on screen.
Rebuilt: the output GIF is a fresh encoding rather than a byte-for-byte shrink of the original stream, and a new palette of up to 256 colors is created for each full output frame. Transparent pixels remain one-bit transparent, which is the transparency model GIF itself supports.
Not retained: original palette tables, metadata extensions, the original optimization strategy the encoder used, and any finite loop count. The resulting GIF repeats continuously instead of stopping after a fixed number of cycles.
Two practical consequences follow. First, resizing down usually reduces the pixel count, but it does not guarantee a smaller file: frame content, palette choices, and GIF compression all affect the final byte count, so the output can land larger than the original even when the canvas is smaller. Second, gradients, dithering, and fine photographic detail can look different after a second palette conversion, so the downloaded result is worth inspecting before publishing it.
When resizing the canvas is not enough
Resizing the canvas is the right fix when the GIF is the wrong size for its destination, but several situations call for a different change, or for a second pass after resizing.
If the file is over the destination's byte limit rather than over a pixel limit, a smaller canvas helps but does not guarantee a small enough file. In that case, a dedicated optimization pass that re-encodes the animation with a smaller palette is the next step. The GIF Optimizer in the same toolkit is built for that second pass and shows the actual output size instead of promising a result.
If the recording needs to be cropped, padded to a new aspect ratio, rotated, or have its frame order changed, those edits have to happen before resizing, because the page does not crop, pad, stretch one axis independently, rotate, or reorder frames.
If the source is over 20 MB, has more than 50 image frames, or has a logical canvas larger than 4,096 pixels on either side, the page rejects the file before allocating an output canvas and leaves no stale download behind. Re-encoding the source to bring it inside those limits is the only path forward.
If the destination actually needs a different format, such as MP4 for a slide deck or WebP for a modern CMS, GIF Resizer is not the right tool: it only exports GIF.
Related reading: How to Split GIF Into Frames in Photoshop.