Yes, I would use this, and I can tell you exactly where the gap is, because I built the same thing for myself a few months ago and then measured it to death 🎮
I run a browser arena game and I ship GIFs into devlogs, forum posts and comment threads constantly. My version is a shell script wrapped around ffmpeg that encodes, measures, shrinks and retries until it fits a byte budget — which is the same loop you have described. So take all of this as notes from someone who has already hit the walls, not as a critique of a tool I have not run.
The thing I think you are missing, and it is the whole game.
Duration is a far bigger lever than any encoder setting, and your users do not know that. Size scales with width × height × fps × duration, so a long clip spends its entire budget on length and then your search has no choice but to shrink the picture to a postage stamp to make it fit.
Measured on one of my own clips, same 3 MB budget, same everything else:
full 14 s -> 360x202
cut to 6 s -> 456x256
Same budget. Noticeably bigger picture, and a GIF that loops on one clear action beats one that plays a whole round at a resolution where nobody can tell what happened.
You already have trimming, so you do not need to build anything new. What you need is for the tool to SAY THIS at the moment it matters. Something like: “at 3 MB this 14s clip lands at 360px wide — trimming to 6s would give you 456px.” That single line turns your tool from an encoder into something that teaches the user the thing that actually controls their output quality. Nobody else’s GIF tool does this and it costs you one extra encode to estimate.
Three more, in order of value.
Add a crop step, because it is free resolution. My raw captures are 2130x1820 with a huge amount of dead black around the playfield. Cropping to the play area alone is pure gain at any budget — you are simply not spending bytes on pixels nobody looks at. If you want the impressive version, auto-detect static borders across a few sampled frames and offer the crop; most game captures have letterboxing, HUD margins or desktop chrome that is identical in every frame.
Be careful about the ORDER your search makes concessions in. The naive implementation drops fps first, because it is the single biggest byte win. It is also the one that most damages perceived quality. My floor after testing: 15 reads as smooth, 12 is acceptable, below 10 looks broken and people read it as a bad game rather than a bad GIF. So shrink width before you drop fps below about 12. If you expose one advanced setting, make it that floor.
Give people a benchmark. Here is mine so you can sanity-check your export quality, since right now you have no external reference: roughly 6 seconds of 2130x1820 gameplay footage, cropped to the arena, at a 3 MB budget, lands around 500 to 640 px wide at 15 fps with a 128-colour palette. If yours comes out materially smaller than that at the same budget and duration, your palette generation or your search step size has room in it. If it comes out bigger, I would like to know what you are doing differently.
On “is this actually useful to other devs” — yes, but the market is narrower than you might be pitching it, and being precise about that will help you. Anywhere that accepts video, video wins: it is smaller and sharper at the same quality. GIF is specifically for the places that will inline an animated image but not a video file, which on itch means forum posts and comment threads. That is a real and recurring need, it just is not “all game media”. Naming that clearly on your page would make the tool feel sharper rather than smaller.
One small heads-up, entirely practical: the link in your post has a utm_source parameter stuck on the end of it. Every click from this thread will be attributed to that source in your itch analytics, so your own referrer data for this launch will be wrong. Worth stripping before you post it anywhere else.
Nice to see someone solve this properly instead of eyeballing it in an online converter ⚡