DALL·E API

The name outlived the models

DALL·E is what people still call OpenAI's image generation, and it is no longer what the models are called. The current line is gpt-image, reached through the Image API and the Responses API.

Two models, split by job rather than tier:

That split is worth knowing before you benchmark. If your product edits images across several turns, the faster model is the wrong one to evaluate, and a comparison run on generation alone will point you at it.

Image generation covers what is true of any provider: how the request differs from a text call, why editing is not regeneration, what you have to store, and what ships inside the file. This page is OpenAI's parameter surface.

Size has rules, not options

Three sizes are recommended: 1024x1024, 1536x1024, 1024x1536. The default for size is auto.

Custom dimensions are accepted as WIDTHxHEIGHT, with three constraints worth writing into a validator rather than discovering in production:

• width and height must be multiples of 16
• the aspect ratio must be between 1:3 and 3:1
• neither edge may exceed 3840 px

A UI that lets a user type dimensions will produce requests that violate the first of those, because 1000 is a rounder number than 1008.

Quality is a five-step dial

quality accepts low, medium, high, xhigh, max, and auto.

Five steps plus auto is more range than most products need, and the useful consequence is that the cheap end is cheap. If you generate a preview the user will accept or reject before you produce the real thing, generate the preview at low. Most workflows that feel expensive are paying high for images nobody kept.

The output parameters that matter downstream

output_format takes png (the default), jpeg or webp, with output_compression from 0 to 100 for the two lossy ones.

background takes transparent, opaque or auto. This is the one to notice: transparency is a request parameter, not a post-processing step, and asking for it here beats cutting one out afterwards. It also forces png or webp, since jpeg has no alpha channel.

n generates several images in one request, which is the right way to give a user a choice rather than making them ask again.

Show progress on a slow request

Complex prompts can take up to two minutes. That is long enough that a spinner is not an adequate answer.

partial_images accepts 0 to 3 and streams intermediate results. Rendering those turns a two-minute wait into something a user will sit through, and it costs you nothing but the wiring.

Editing, and the mask requirement

Edits modify an existing image, partially or entirely, and come in three shapes.

Reference-based generation passes input images to guide a new one.

Mask-based inpainting replaces a region. The requirement that trips people up: the mask image must contain an alpha channel. A black-and-white PNG looks like a mask and is not one.

Multi-turn editing through the Responses API, chaining with previous_response_id, which is also where you can pass image File IDs rather than bytes. For an editing session that is the difference between re-uploading the image on every turn and referring to it.

Moderation runs at both ends

moderation takes auto (the default) or low.

A blocked request returns error.code of moderation_blocked, optionally with moderation_details naming the stage, input or output, and the categories.

Read that stage field and handle the two differently. An input block is the user's prompt and they can be told to rephrase. An output block means the model produced something that failed on the way out, and the user did nothing they can correct. The same generic error message for both is the wrong answer half the time.

What it is still poor at

Two documented weaknesses. Text rendering remains hard, so a design with words in it will need them added afterwards. And precise composition is inconsistent between requests, so "the logo in the upper left" is a suggestion rather than an instruction.

Both are reasons to keep a human in the loop for anything that ships to a customer, and reasons to prefer n over one hopeful request.

Further reading

• OpenAI, Image generation: the models, every parameter, the size constraints and the moderation errors.
• Image generation: the decisions that apply to any provider.
• Nano Banana API: Google's equivalent, and a different editing model.
• OpenAI Vision API: the other direction, images in.