Trim to the seconds that matter, choose the frame rate and the width, and watch the finished GIF before you download it — decoded and encoded in this tab.
Runs in your browser0 bytes uploadedDrop a video here
Nothing is uploaded. The clip is decoded by the same code that plays it in this tab.
People arrive here expecting the output to be smaller, because a GIF feels like a lesser thing than a video. It is almost always larger, often by a factor of ten, and knowing why is the difference between fighting the tool and using it well. Modern video compression works across time. It keeps one full picture every couple of seconds and then describes the rest as motion: this block of pixels moved eleven to the left, that region is unchanged, this corner got slightly darker. GIF has none of that machinery. Every frame is a still picture drawn from a lookup table of at most 256 colors, and the single trick available to it is skipping a rectangle that did not change at all between one frame and the next. On a locked-off screen recording that trick pays handsomely. On anything shot handheld it pays nothing, because when the camera moves, every pixel in the frame changes.
The practical consequence is that length and frame count, not quality settings, dominate the result. Two seconds costs a fifth of what ten seconds costs. Twelve frames per second costs half of what twenty-four costs. That is why the trimming controls sit at the top of the panel rather than hidden behind an “advanced” disclosure: they are not a refinement, they are the whole negotiation.
As soon as a clip is open, the panel reports its running time, its true pixel dimensions and — where the browser is willing to be measured — how many frames per second it actually plays. No browser reports that last figure directly, so it is timed here from real presented frames rather than assumed, and when the measurement fails the panel says so instead of printing a plausible number.
Two further figures update as you change the settings. The first is how many frames your choices will produce, which is the closest thing to a price tag this format has. The second is how much decoded picture has to sit in memory to play the result back, calculated exactly as width times height times four bytes times frames. That second figure is the one that matters and the one nobody shows you. A tab does not usually die of a large download; it dies of holding nine hundred decoded frames at once, and when it does it reloads itself without explanation. Nothing here refuses to run on account of a big number. It tells you the number first and then does what you asked.
A GIF does not store a frame rate. It stores a delay beside every frame, counted in hundredths of a second, which has two consequences worth knowing. The first is arithmetic: a request for 30 frames per second needs 3.33 hundredths per frame, and only whole numbers can be written. Rounding each frame separately drifts, so the remainder is carried forward here and the total running time lands where it should. The receipt states the duration the file actually declares, not the one you asked for, and on a well-behaved rate they are the same.
The second consequence is a hard ceiling. A delay of one hundredth is played by every browser as ten hundredths — a compatibility decision inherited from the Netscape era that can never be undone without breaking a large fraction of the animated images on the web. Two hundredths is therefore the shortest delay anyone honors, which puts the real ceiling at 50 frames per second. Ask a converter for 60 and you will get a file that plays at 10. The selector here stops at 50 and explains itself, and it also stops at whatever the source clip runs at, because asking for more frames than exist writes the same picture twice at full cost.
Your browser already contains everything needed to play the file you dropped: a container parser, a hardware-backed decoder, a compositor. This page borrows all three. Frames are drawn out of a real video element into a canvas at the target size, handed to a background thread, reduced to a shared palette with median-cut quantization and compressed with the LZW coder that GIF has used since 1987. Your clip is never sent across a network, because there is no service on the other end of one — the whole conversion is code running in the page you are looking at. That also means the format support you get is exactly the format support your browser has: MP4 and WebM everywhere, MOV and HEVC where the operating system provides them. When a file will not open, the tool names the likely reason rather than shrugging.
There is no cropping, no rotation, no text, no filters, no speed ramp and no audio handling, because GIF has never carried sound. If the destination will accept a video, it is worth asking whether it should be a GIF at all;converting the other way, from GIF to MP4, typically cuts the same animation by an order of magnitude and is the right move for anything that lives on a web page you control. And if you already have a GIF that is simply too large to send, compressing it to a target size spends colors, frames and resolution in that order and reports which levers it had to pull.
Drop the file on this page, drag the two handles to the part you want, and choose a frame rate and a width. Ten frames per second at 480 pixels wide suits almost everything. The panel shows how many frames that comes to before anything runs, which is the number that decides both the file size and whether your browser will enjoy playing it back.
Because GIF does not compress time. A video stores what changed between one frame and the next; a GIF stores each frame as its own picture, drawn from a table of at most 256 colors, and the only saving it can make is skipping rectangles that did not move at all. Ten seconds that fit in a 2 MB MP4 routinely need 20 MB as a GIF. Halving the frame rate roughly halves the file, and so does halving the width.
Between 10 and 15 for most things. GIF stores each delay in hundredths of a second, so 50 frames per second is the format ceiling and anything above it is silently played at ten by every browser. Fifteen looks smooth for motion, ten is the usual compromise, and five is fine for a slow screen recording and costs half as much.
Not here. Your browser already contains the decoder that plays the file, and this page samples frames straight out of it, quantizes them to a palette and writes the GIF bytes on a background thread. There is no server in the path, which is why the work starts the moment you drop the file instead of after a queue, and why a clip you would never hand to a website is fine to convert.
A .mov straight off an iPhone is usually HEVC, and support for it is a property of your browser rather than of the file. Safari and Chrome on a Mac decode it; Chrome on Windows generally does not. If the tool says it cannot play the clip, opening this page in Safari is the fastest fix, and exporting the clip as H.264 makes it work everywhere.