Choosing a GPT-Image Model and Sizing a Generation Request

What the catalogue looks like now

Before anything else, clear one thing out of the way, because it is the most common source of stale answers on this topic. DALL-E 3 was retired on 4 March 2026. It is no longer available for new deployments, and existing deployments are non-functional. If you studied older material, every mention of DALL-E as the image generator on Azure is now history. The current family from this provider is the GPT-Image series, and that is what a text-to-image scenario in Foundry uses today.

Within that family the models differ along axes that matter to a project plan, not just to a benchmark.

GPT-Image-2 is generally available — the one you can build a production commitment on. It is the strongest option for high-resolution and 4K generation, has improved editing performance, and supports a broad range of aspect ratios.

GPT-Image-1.5 and GPT-Image-1 are limited-access previews you must apply for. Both target realism, instruction-following, and multimodal context; 1.5 improves speed and cost over 1.

GPT-Image-1-Mini is the cost-efficient, faster member, suited to fast prototyping, bulk generation, or cost-sensitive workloads. Its defining limitation is that it has no dedicated face preservation, which makes it a poor fit for portrait work and a fine fit for general creative imagery.

The availability column is as important as the strengths column. "Limited access preview" means an access application stands between your design and your deployment, and that is a schedule risk you should surface early rather than discover during implementation.

Output arrives as base64, always

The models in this family accept text and image inputs and return images only as base64 — there is no URL option. This single fact reshapes the code you write.

You are not handed a link to a hosted asset. You receive encoded bytes in a b64_json field, and your application owns everything that happens next: decoding, choosing a storage location, generating a URL if your users need one, and applying whatever retention policy your organisation requires. Nothing expires on its own because nothing is hosted on your behalf. Plan storage and lifecycle as part of the feature, not as an afterthought.

The parameters that shape a request

Size. For the GPT-Image-1 series you pick one of three fixed shapes: square, portrait, or landscape at 1024 and 1536 pixels. Square images are faster to generate. GPT-Image-2 lifts that restriction and accepts arbitrary resolutions, subject to real constraints — both edges must be a multiple of 16 pixels, the long edge goes up to 3840 pixels for 4K, the aspect ratio can reach 3:1, and the total pixel count must fall between 655,360 and 8,294,400. There is a subtlety worth remembering: those constraints only apply when you specify a size. If you let the service choose automatically, the result may not satisfy them, so layouts that depend on exact dimensions should state the size rather than trust the default.

Quality. Three options — low, medium, high — with lower quality generating faster. The default is high. GPT-Image-2 reworks these controls, with low tuned specifically for latency-sensitive scenarios. Quality is your main latency dial, and in interactive products it is usually the right one to reach for first.

Number. You can request between one and ten images in a single call, defaulting to one. This is how you build a candidate grid for a human to choose from, and it is far more efficient than issuing ten separate calls.

Output format and transparency. PNG and JPEG are supported, with PNG the default; WEBP is not supported here. For a transparent background you set the background parameter to transparent and the output format to PNG — the two settings are a pair, and setting only one of them silently gives you an opaque image. Compression applies to the lossy path.

Streaming. Enabling streaming returns partial images as they are generated, with a parameter controlling how many partials you get. This does not make generation faster; it makes it feel faster, which in a user-facing product is often the more valuable of the two.

Quota is smaller than people expect

Image generation carries default rate limits per deployment, and the default is five images per minute. That is a per-deployment ceiling, not a per-subscription one, and it is low enough that a modest demo can hit it. Check your quota in the portal and request an increase before a launch, not during one.

Common mistakes

Writing code that expects an image URL. There isn't one; decode the base64 and store it yourself.

Designing a feature around a limited-access preview model without starting the access request.

Asking for a transparent background while leaving the output format as JPEG.

Assuming five images a minute will scale, and discovering otherwise in front of an audience.

And carrying forward a design that names DALL-E. That deployment path no longer exists.