Ezgif Alternative: Batch GIF Conversion Past the 100 MB Cap

You have a folder of 140 clips and a tool that takes them one at a time, through a browser form, with an ad refresh between each one. Ezgif does a clean job on a single file. It has no way to accept a folder, and no way for your workflow to call it.

Quick answer: The best Ezgif alternative for batch GIF conversion is FFmpeg's two-pass palettegen/paletteuse filter chain run in a shell loop, which has no upload cap and converts a whole folder unattended. Ezgif caps video-to-GIF uploads at 100 MB, handles one file per page load, and publishes no API, so anything past a handful of files needs a script or a hosted job API. FFmpeg Micro runs that same palette-optimized conversion as one API call per file, with a free tier and no encoder to install.

Ezgif's ceiling is the upload form, not the encoder

Ezgif's limits come from how it accepts files, not from how well it converts them. The video-to-GIF page takes uploads up to 100 MB. Several of the other tools on the site (the optimizer, the resizer, the frame editor) cap far lower, in the single-digit megabytes, because they're working on already-decoded GIF frames. Check the number printed on the upload page before you plan around it, since it moves.

The size cap is the limit people hit first. The one that actually blocks a pipeline is different: Ezgif has no public API and no batch queue. Every conversion is one file, uploaded through a browser form, downloaded by hand. There's a GIF maker that assembles several images into one GIF, but that's a single output from many inputs, not many outputs from many inputs.

So the common read ("I need a bigger free converter") is half right. A 400 MB screen recording won't upload. But if you swap Ezgif for another free web converter with a higher cap, you still click through 140 times. The constraint isn't megabytes. It's that a web form can't be called by a for loop.

The command Ezgif runs when you click Convert

Ezgif's video-to-GIF tool wraps the same palette workflow you can run locally. GIF is limited to 256 colors per frame, so quality depends almost entirely on which 256 colors get picked. FFmpeg's default GIF encoder uses a generic palette. The palettegen filter builds one from your actual frames instead.

The single-command version, using split so the source is decoded once:

ffmpeg -i input.mp4 -vf "fps=12,scale=480:-1:flags=lanczos,split[a][b];\
[a]palettegen=stats_mode=diff[p];\
[b][p]paletteuse=dither=bayer:bayer_scale=5:diff_mode=rectangle" \
-loop 0 output.gif

Three parts of that line do the real work. fps=12 sets how many frames the GIF holds per second, scale=480:-1 sets the width and lets height follow the aspect ratio, and stats_mode=diff tells palettegen to weight colors by what changes between frames rather than what fills the static background.

Those first two numbers are your file size. A 480x270 GIF at 12 fps for 10 seconds is 120 frames of 129,600 pixels each. At one byte per pixel indexed color that's about 15 MB before compression, and LZW plus frame differencing usually lands it somewhere between 1 MB and 4 MB depending on how much motion there is. Double the width to 960 and you roughly quadruple the pixel count. Raise fps from 12 to 24 and you double the frame count. Nothing else you change will matter as much.

Batch convert GIFs by looping over a folder

Batch conversion is a shell loop around that command, and it runs while you do something else. Put the sources in in/, create out/, and run four conversions at a time:

mkdir -p out
ls in/*.mp4 | xargs -P 4 -I{} sh -c '
  f="{}"; b=$(basename "$f" .mp4)
  ffmpeg -v error -y -i "$f" \
    -vf "fps=12,scale=480:-1:flags=lanczos,split[a][b];\
[a]palettegen=stats_mode=diff[p];\
[b][p]paletteuse=dither=bayer:bayer_scale=5:diff_mode=rectangle" \
    -loop 0 "out/$b.gif" || echo "FAILED: $f" >> out/errors.log
'

-P 4 is the concurrency. GIF encoding is mostly single-threaded per file, so running one job per core beats letting FFmpeg spread one file across all of them. -v error keeps the output quiet enough that the failure log means something, and the || branch records which inputs died instead of silently producing a zero-byte GIF.

For the other direction, converting a pile of legacy GIFs back to MP4 to cut page weight, the loop is the same shape with a different command. That conversion has its own trap around odd pixel dimensions, which is covered in how to convert GIF to MP4 with FFmpeg and in the fix for FFmpeg's "height not divisible by 2" error.

Where a local batch stops being the answer

A local loop stops paying off the moment the files aren't on your laptop. If clips land in Google Drive from a form, or in S3 from a mobile app, or in an n8n node from an RSS trigger, then "download everything, run FFmpeg, upload everything" is a worse pipeline than one call per file. Automation runners make this harder, not easier: n8n holds file binaries in memory and falls over on large video, and Zapier and Make both time out long before a 200-clip encode finishes.

That's the step FFmpeg Micro replaces. You send each file as one API call, the job runs on managed FFmpeg with no binary to install and nothing to keep alive, and you poll or take a webhook when the GIF is ready. The same batch loop, pointed at the API instead of a local binary:

# Endpoint path, auth header, and field names: https://www.ffmpeg-micro.com/docs
ls in/*.mp4 | xargs -P 8 -I{} sh -c '
  curl -sS -X POST "https://api.ffmpeg-micro.com/<jobs endpoint from docs>" \
    -H "Authorization: Bearer $FFM_KEY" \
    -F "file=@{}"
'

Concurrency moves from your CPU count to whatever the queue will take, and a 400 MB source is the same job as a 4 MB one. If you'd rather not write the loop at all, the Video to Animated GIF blueprint is this exact conversion as a one-click page with length, width, and optional caption options, and the MCP server exposes it as a tool call for agents.

Here's the honest comparison across the three paths:

Pitfalls that make GIFs huge or ugly

Most bad GIF output traces back to a handful of settings, and they're the same ones whether you're using a web tool or the command line.

When Ezgif is still the right call

Ezgif is genuinely good at one thing this post doesn't replace: eyeballing a single file. If you want to crop a GIF by dragging a box, trim by scrubbing, or try four dither settings and look at all four, a visual tool beats re-running a filter chain. Nothing here argues you should script a job you'll do once.

The line is repetition and integration. One file, tuned by eye, stays in the browser. A folder, or a recurring step in a workflow, needs something a script can call. And if what you actually need is a timeline with keyframes and layers, neither a shell loop nor a job API is the tool. That's a video editor, and this is a conversion pipeline. The same split shows up in the broader file-conversion market, which is why your job usually isn't a conversion at all.

FAQ

What is Ezgif's file size limit?

Ezgif's video-to-GIF converter accepts uploads up to 100 MB. The GIF-editing tools (optimizer, resizer, frame editor) cap much lower, in the single-digit megabytes, because they operate on decoded frames rather than a compressed video stream. The number is printed on each tool's upload page and has changed over time, so check it there rather than assuming.

Does Ezgif have an API?

Ezgif publishes no public API and no batch endpoint. Every conversion happens through a browser form, one file per page load, which means you can't call it from n8n, Make, Zapier, a cron job, or your own code. That's the practical reason people look for an alternative, more often than the size cap.

How do I convert a whole folder of MP4 files to GIF at once?

Run FFmpeg's palettegen/paletteuse chain inside a shell loop over the folder, using xargs -P 4 to convert four files at a time. Set fps=12 and scale=480:-1 in the filter chain to keep output sizes reasonable, and log failures with || echo "FAILED: $f" so one bad input doesn't quietly break the batch.

Why is my GIF bigger than the video it came from?

A GIF stores each frame as its own indexed-color image with no interframe motion prediction, while H.264 in an MP4 predicts most frames from their neighbors. That's why a 3 MB MP4 becomes a 12 MB GIF at the same size and frame rate. Lowering fps and width are the only two levers that meaningfully shrink it.

Is there a free way to batch convert GIFs without installing FFmpeg?

FFmpeg Micro has a free tier that runs palette-optimized video-to-GIF conversion as an API call, with no FFmpeg binary and no server on your side. Pricing past the free tier is usage-based and listed at /pricing.

Point the loop at your own folder, pick an fps and a width, and let the queue chew through it. Sign up free and run the first batch on the free tier before you decide whether it's worth wiring into the workflow.