Back to blog
Video13 min read

Aspect Ratio Reference for Every AI Model (Image and Video)

Checked against each vendor's own docs, Sep 3 2026: Gemini's aspect ratio enums differ between its API guide and Vertex model card; FLUX takes a free-text range; GPT Image 2 has no ratio field.

NH
Nafiul Hasan
Founder, Prompt Architects

TL;DR: "Aspect ratio" is not one field. Midjourney takes a free integer ratio in the prompt, Gemini and Kling pick from a closed enum, FLUX's top models take a free-text range, and GPT Image 2 takes raw pixels instead. Checked against each vendor's own docs on September 3, 2026, with the field name, exact values, and date for every row below.

Why Isn't "Aspect Ratio" One Field Across Every AI Model?

Because every vendor built its own request shape around its own architecture, with no coordination between them. A cheat sheet that lists "supported ratios" per model without naming the field and its type hides the part that actually breaks an integration.

Read across the ten models here, aspect ratio takes at least six distinct forms:

  1. A free integer ratio in the prompt itself. Midjourney's --ar W:H takes any integer pair under the version ceiling; there's no fixed list to publish.
  2. A closed string enum. Gemini's aspect_ratio, Kling's settings.aspect_ratio, and Veo's aspectRatio all pick from a fixed list like "16:9".
  3. Raw width/height integers, no ratio concept at all. FLUX.2's pro, max, flex and klein variants take pixel dimensions directly.
  4. A free-text string bounded by a range, not a list. FLUX1.1 Ultra and Kontext take aspect_ratio as a string with a documented range, "between 21:9 and 9:21", and no enumerated values.
  5. Colon-separated pixel dimensions doing double duty as resolution. Runway's ratio field looks like a ratio (1280:720), but its own field description reads "The resolution of the output video."
  6. An enum that shrinks between model versions. Ideogram's support differs across its 3.0 and 4.0 tiers, and Gemini's two documentation surfaces don't even agree on one model's list, covered next.

What Aspect Ratios Can Image Models Actually Generate?

A field name, a mechanism, and the exact values, per vendor's own current documentation.

Model (version, checked)FieldMechanismValuesDefault
Midjourney V8.1 / V8.2 (Aspect Ratio doc, updated Jul 27, 2026)--ar / --aspectFree integer ratio in the prompt textAny integer W:H, no decimals; capped 14:1 in SD, 4:1 in HD1:1
Gemini 3.1 Flash Image, "Nano Banana 2" (ai.google.dev, checked Sep 3, 2026)aspect_ratio in response_formatClosed enum14 values: 1:1 1:4 1:8 2:3 3:2 3:4 4:1 4:3 4:5 5:4 8:1 9:16 16:9 21:9Matches the input image, else 1:1
Gemini 3.1 Pro Image, "Nano Banana Pro" (same API guide, checked Sep 3, 2026)aspect_ratioClosed enum, narrower on this surface10 values: 1:1 2:3 3:2 3:4 4:3 4:5 5:4 9:16 16:9 21:9Same
Same model, Vertex model card (docs.cloud.google.com, checked Sep 3, 2026)Listed as "Supported aspect ratios"Closed enum, wider than the API guide15 values, adding 1:4 4:1 1:8 8:1 9:21 to the ten above
FLUX.2 (flux-2-pro, -max, -flex, -klein-4b/9b) (api.bfl.ai/openapi.json, checked Sep 3, 2026)width + heightRaw pixels, no ratio field existsIntegers, minimum 64px each side; no stated maximum, BFL's own ceiling elsewhere is roughly 4 megapixels
FLUX1.1 Ultra / Kontext Pro & Max (same source)aspect_ratioFree-text string bounded by a range"Aspect ratio of the image between 21:9 and 9:21" — not a list16:9 (Ultra)
GPT Image 2, gpt-image-2-2026-04-21 (OpenAI openapi.yaml + image guide, checked Sep 3, 2026)sizeArithmetic constraint region, not a listAny WIDTHxHEIGHT: both edges divisible by 16, ratio between 1:3 and 3:1, max edge ≤3840px, total pixels 655,360 to 8,294,400auto
GPT Image 1 / 1-mini / 1.5, DALL-E 2 / 3 (same spec)sizeClosed enum (the older, simpler shape)1024x1024 1536x1024 1024x1536 plus auto; DALL-E models use their own separate list1024x1024
Ideogram, resolution-led not ratio-ledresolution (+ optional aspect_ratio on the 3.0 generation tier only)Version-scoped WIDTHxHEIGHT enumShrank from roughly 69 presets on the older tier to 38 on the newer one; the API's own x separator convention (16x9, not 16:9) is confirmed on Ideogram's current docs

Sources for the table above: Midjourney Aspect Ratio documentation (updated Jul 27, 2026) · Gemini API image-generation guide · Vertex Gemini 3 Pro Image model card · BFL OpenAPI spec · OpenAI image-generation guide · Ideogram aspect ratio and dimensions doc — all accessed September 3, 2026.

Midjourney's full ratio-to-pixel table, including which four ratios it actually publishes exact dimensions for and why --ar 16:9 doesn't render at a mathematically exact 16:9, already has its own dedicated page. This table doesn't repeat it.

Why Do Google's Own Pages Disagree on Gemini's Aspect Ratios?

Because Gemini's image models are documented on at least two separate Google-owned surfaces, and the two lists were evidently not generated from the same source of truth.

The Gemini API's image-generation guide gives Gemini 3 Pro Image, marketed as Nano Banana Pro, exactly 10 supported ratios: 1:1, 2:3, 3:2, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9, 21:9. The Vertex model card for the identical model ID, gemini-3-pro-image, lists 15: the same ten, plus 1:4, 4:1, 1:8, 8:1 and 9:21. Same model, same day, two different enums, neither labeled authoritative. The honest answer to "does Gemini support 1:8" depends which of Google's own pages you're calling against, so test the actual endpoint rather than trust either list blind.

A second inconsistency shows up only in the pixel math, not the labels. Gemini 3.1 Flash Image's own resolution table lists 21:9 as 792x168 at its smallest tier and 1584x672 at the next tier; every other ratio in that table doubles cleanly between tiers, but 168 doubled is 336, not 672. Gemini 2.5 Flash Image, the older fixed-resolution model on the same page, gives 21:9 as 1536x672 instead, a different pixel count for the identical label. Google asserts none of this as a discrepancy; it's visible only by reading the numbers, not the ratio names next to them.

Does Any Model Actually "Snap" Your Aspect Ratio to the Nearest One It Supports?

Mostly no, and where it happens, it's usually documented rather than silent. Worth being precise here, because the "AI quietly substitutes the nearest ratio" line gets repeated as universal folklore, and most vendors checked for this piece never say it anywhere.

Two real, vendor-stated exceptions exist, and they differ from each other. Ideogram documents outright normalization. Its own aspect-ratio page states: "When custom dimensions are available, Ideogram may normalize your requested dimensions to a supported ratio, model size, or resolution tier." Midjourney's case is narrower, about pixels rather than ratio choice. Its docs state only: "Some aspect ratios may be slightly changed when upscaling." That's scoped specifically to the upscale step. The full breakdown of how far a requested 16:9 lands from mathematically exact is on its own page; the short version is Midjourney's output snapping to a 16-pixel grid, nudging non-dividing ratios by well under half a percent.

Everyone else here either rejects an out-of-range value (undocumented as an error, in most vendors' APIs) or simply offers a field too short a list to need rounding at all. If your integration produces an unexpected ratio, suspect a wrapper or SDK default overriding your request before you suspect the model rounding it.

What Aspect Ratios Can Video Models Actually Generate?

Same format: field, mechanism, values, checked against each vendor's own current docs.

Model (checked)FieldMechanismValuesDefault
Veo 3.1, 3.1 Fast, 3.1 Lite, 3, 3 Fast (ai.google.dev/gemini-api/docs/veo, checked Sep 3, 2026)aspectRatioClosed enum, identical across every current Veo variant16:9, 9:16 — nothing else, on any surface16:9
Sora 2 / Sora 2 Pro (developers.openai.com, checked Sep 3, 2026)sizeWIDTHxHEIGHT string; guide and spec disagree (see below)Guide: 1280x720 both models, 1920x1080/1080x1920 for sora-2-pro only. OpenAPI enum: 720x1280, 1280x720, 1024x1792, 1792x1024 — no 1080p size at allNot stated in the guide
Runway Gen-4.5, text-to-video (docs.dev.runwayml.com/api.md, checked Sep 3, 2026)ratio, described in Runway's own schema as "The resolution of the output video"Closed enum, colon-separated pixel dims1280:720, 720:1280None — required field
Runway Gen-4.5, image-to-video (same source)ratioClosed enum, wider than text-to-video1280:720, 720:1280, 1104:832, 960:960, 832:1104, 1584:672None — required field
Kling 3.0 Omni, text-to-video (kling.ai/document-api, checked Sep 3, 2026)settings.aspect_ratioClosed enum16:9, 9:16, 1:116:9
Kling 3.0 Omni, image-to-videoNo aspect_ratio field publishedOutput inherits the input image's shapeInput image itself must be between 1:2.5 and 2.5:1Inherits input
Luma Ray 3.2 (docs.agents.lumalabs.ai, per this project's Sep 2, 2026 verification)aspect_ratioClosed enum, unusual in having no forced default9:16, 3:4, 1:1, 4:3, 16:9, 21:9None forced — the model infers a ratio from the prompt if the field is omitted

Sources: Veo on Gemini API · Sora video-generation guide and OpenAI's deprecations page · Runway API reference · Kling 3.0 Omni text-to-video reference — all checked September 3, 2026. The Luma Ray 3.2 row carries forward this project's September 2, 2026 verification rather than being re-fetched today; say so rather than passing it off as freshly checked.

If you're assembling a full Veo request rather than just the ratio field, our Veo 3 prompt structure guide covers the rest, and post 234 covers the duration field this one is usually paired with. Post 362 goes further on the video side specifically, including which platforms want which ratio once you've generated the clip; this page stops at the request parameter itself.

Is Sora's Aspect Ratio Even Worth Building Around Right Now?

Only briefly. OpenAI's own deprecations page schedules the entire Sora API for removal on September 24, 2026, sora-2, sora-2-pro and every dated snapshot listed, no replacement model named. As of this post's publication that's about three weeks out. Post 192 covers where those prompts should move instead.

Even live, Sora's own documentation doesn't agree with itself on sizes. The video-generation guide's prose and examples point to sora-2-pro supporting 1080p exports at 1920x1080 or 1080x1920, alongside the base 1280x720. The OpenAPI spec's own VideoSize enum lists exactly four values instead: 720x1280, 1280x720, 1024x1792, 1792x1024, no 1080p size present, plus two values absent from the guide entirely. Both are OpenAI's own current documents, checked the same day; state both rather than picking one.

Copy-Paste Aspect Ratio Settings for Every Model

The prompt text never carries the ratio on any model checked here; it's always a separate field, set to 9:16 in every example below so you can compare the shape directly.

// Gemini 3.1 Flash Image or Pro Image (Nano Banana / Nano Banana Pro)
{
  "model": "gemini-3.1-flash-image",
  "input": "...",
  "response_format": { "type": "image", "aspect_ratio": "9:16", "image_size": "2K" }
}
# FLUX1.1 Ultra (free-text range, not an enum)
curl -X POST https://api.bfl.ai/v1/flux-pro-1.1-ultra \
  -H "x-key: $BFL_API_KEY" -H "Content-Type: application/json" \
  -d '{"prompt":"...","aspect_ratio":"9:16"}'
# GPT Image 2 (no ratio field — width and height directly)
curl https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" \
  -d '{"model":"gpt-image-2","prompt":"...","size":"1024x1536"}'
// Veo 3.1, Gemini API
{
  "instances": [{ "prompt": "..." }],
  "parameters": { "aspectRatio": "9:16", "durationSeconds": "8" }
}
// Runway Gen-4.5, image-to-video (colon-pixel-dims form)
{ "model": "gen4.5", "promptImage": "...", "promptText": "...", "ratio": "720:1280" }
# Kling 3.0 Omni, text-to-video
curl --location 'https://api-singapore.klingai.com/text-to-video/kling-3.0' \
  --header 'Authorization: Bearer {apikey}' --header 'Content-Type: application/json' \
  --data '{"prompt":"...","settings":{"aspect_ratio":"9:16","duration":10}}'

Get the field name wrong and most APIs don't error cleanly; they reject the whole request or silently fall back to a default, which reads exactly like the "snapping" behavior the earlier section said isn't actually documented. It isn't the model rounding your ratio; it's your request never reaching the field at all.

Free Chrome Extension

Stop rewriting prompts. Start shipping.

Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.

Create An Account

Aspect Ratio Is Not Resolution: Where the Two Axes Split

Everything above answers one question: what shape can you ask for. It deliberately skips a second, related question: how many pixels you get at that shape. Ideogram's enum is really a resolution enum wearing an aspect-ratio hat, since one WIDTHxHEIGHT preset sets both at once; Gemini and Veo keep the two as genuinely separate fields you set independently.

Treating them as one axis is how a "4K aspect ratio table" ends up conflating two different vendor decisions: which shapes a model will draw, and how many pixels it spends on any given shape. This page covers only the first. For pixel counts and megapixel ceilings, check the specific model's own documentation; every source cited above links straight to it.

Frequently asked questions

Free Chrome Extension

Stop rewriting prompts. Start shipping.

Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.

Create An Account