GPT Image 2.6 TeamThe short answer: a GPT Image 2.6 edit cannot make a GIF because GIF output is wired to the generation endpoint only. POST /v1/images/generations builds a short animation frame by frame, while the edit endpoint takes your picture and returns a changed one. OpenAI's guide states the rule in one line: "GIF output is for image generation; the image edit endpoint does not support GIF output." So a photo you already have will not turn into a loop through an edit call. The photo can still steer the result, but the loop comes from a generation request, where you describe the scene again in words.
The rule is a route, not a defect
GIF support is not missing from the edit endpoint by accident; it lives on a different endpoint with a different shape. An edit request holds your file and returns the same picture, changed where you asked. A GIF request has to hold a timeline: how many frames, how long each one lasts, and how large each one is. Those are two different jobs, so the API keeps them apart.
POST /v1/images/generations |
POST /v1/images/edits |
|
|---|---|---|
| Input | A prompt | Your uploaded picture |
| Output | New pixels drawn from the prompt | The same picture, changed |
output_format: "gif" |
Supported | Not supported |
frame_count, frame_duration_ms |
Accepted | Not accepted |
The last two rows follow from that one line: the frame fields belong to GIF output, and GIF output is generation only. Nothing else in the request changes that.
What this means for the photo you want to animate
Your photo cannot be the thing that gets animated, and that is the whole of the bad news. The picture is fine; what changes is the job you are asking for: the loop is a new animation built around your subject, not an effect applied to your file.
So the practical question is no longer "how do I edit this into a GIF". It is "how do I get the model to draw this again, in motion". There is one route through the API, and one form field that looks like a shortcut and is not one.
Describe the scene again in a generation prompt
The generation endpoint takes a prompt instead of an upload, so you rewrite what the photo shows in words. Name the subject, the material, the colors, the light and the framing. Then add the motion, which is the part your photo cannot supply.
OpenAI's prompting advice for loops is short and specific: give the subject a starting pose to return to, and say whether the camera should move. That is OpenAI's own recipe for a smooth loop: the last frame lands where the first one began.
A prompt built that way, for a photo of a mug on a desk, reads like this:
A glazed ceramic mug on a wooden desk beside a window, soft side light, shallow depth of field, camera locked off. Steam rises and curls back down while the mug stays still. End on the starting pose so the loop has no jump.
The richer the description, the closer the result sits to your photo. The limit is your own eye: everything you leave out, the model is free to invent.
The reference image field is not a shortcut
On this site the reference image field stays visible when you choose the animated format, and it takes up to 16 images, but a reference image is not a way to animate your photo. A run that carries one goes to the upstream edit endpoint, and that endpoint does not support GIF output, so the animated format has no support on that path. The two halves cannot be combined: the reference steers a still image, while the frame fields shape a loop, and they live on different endpoints.
OpenAI's own API keeps the same split: reference images belong to the edit request, which is the request that cannot return a GIF. So for a GIF, put what matters about the photo into words instead — subject, material, colors, light and framing are what survive into the loop.
Frame controls only exist on the generation request
Two fields shape a loop, and both belong to the generation call. frame_count takes 2 to 64 frames and defaults to 9. frame_duration_ms takes 20 to 2000 milliseconds per frame, rounds to 10 ms, and defaults to 200.
Multiply the defaults and you get 1.8 seconds: nine frames at a fifth of a second each, with nine poses to carry the whole movement.
| Goal | Field to change | Side effect |
|---|---|---|
| Smoother motion | frame_count up |
More frames drawn, so more of the pixel budget |
| Faster playback | frame_duration_ms down |
Shorter loop |
| Longer loop | frame_count up, or frame_duration_ms up |
The second option lengthens the loop without new drawings |
size describes each finished frame, not the stitched result, and it takes auto or a WIDTHxHEIGHT with both sides as multiples of 16. Frame count, frame size and n all share one model size limit and one pixel budget. When a request goes over, the guide's fix is to reduce frame_count, the frame dimensions, or n.
GIF output also skips streaming, partial images, custom output_compression and prompt_rewriter. Those are not settings you forgot to find; they do not apply to this output.
On this site, every GIF is 1.8 seconds
The generator here exposes a format choice, Image or Animated GIF, and sends no frame fields, so the defaults hold on every run: every loop comes back at 9 frames of 200 ms. No API key is needed.
Each frame is sized from a 512×512 pixel budget, so a square frame comes out at 512×512 and other aspect ratios get the same budget. The upstream stitches the frames into one sprite sheet, so small frames are what keep a nine-frame loop inside its pixel limit. GIF runs cost 40 credits on Flare and 52 on Sunburst, with 50% added at high quality. Credits and packs are on the pricing page.
If you want the settings in full, from the format field to the prompt wording, the GIF walkthrough covers the whole request.
FAQ
Can I edit an existing GIF with GPT Image 2.6?
No. An edit returns a still image, so a loop has no path through it. To change a GIF you send a new generation request with a changed prompt and build the animation again.
Can I edit one frame of a GIF?
Not through the API. A request returns one finished file, and frame_count and frame_duration_ms shape the whole animation before it runs. To change a single moment, change the prompt and generate the loop again.
Why can't I send the gif format to the edit endpoint?
Because output_format: "gif" and the frame fields belong to the generation endpoint. Move the request to POST /v1/images/generations, keep the subject and the motion in words.
Do I lose my photo's detail if I use the prompt route?
Some of it, yes. The prompt route keeps whatever you describe, so name texture, color and light with care. A GIF request has no reference image input, so for a product, a face or a logo the words are the only thing carrying the look.
Can I make a loop longer than 1.8 seconds here?
Not on this site, because the form sends no frame fields and the defaults always win. Through the API you can go to 64 frames and 2000 ms per frame, as long as the frame count and the frame size stay inside the pixel budget.
Sources
Revision log
- November 5, 2026 — Page published.