TL;DR: An AI image with the wrong aspect ratio is almost always a parameter problem, not a prompt problem. On nearly every surface the ratio is a request field, not something the model reads out of your sentence. Type "make it 16:9" into a prompt box and most surfaces quietly apply their own default instead.
Why did my AI image come out with the wrong aspect ratio?
Because the shape you asked for never reached the model as a setting. On almost every surface that generates images, aspect ratio is a parameter with its own name and its own list of legal values, and the prompt text is not where it lives. Words like "widescreen" or "16:9" sit in the prompt next to your subject and lighting description, carrying no more weight than "moody" or "cinematic".
Midjourney says this outright. Its Aspect Ratio article, updated July 27, 2026, opens with "Midjourney images start as squares, but you can change this using the aspect ratio parameter: --ar or --aspect", and states "The default aspect ratio is 1:1." Google says the same thing from the other direction. The Gemini API image generation documentation, last updated August 26, 2026, states that "By default, the model matches the output image size to that of your input image, or otherwise generates 1:1 squares", and that you control it "using the aspect_ratio and image_size fields under response_format".
Square is not the model misunderstanding you. Square is the documented fallback when nothing set the field.
Which control actually sets the dimensions on each surface?
Every row below was read off the vendor's own request schema or help article on August 27, 2026. Where a vendor documents nothing, the cell says so rather than guessing.
| Surface | What sets the dimensions | Value grammar | Default | Vendor source |
|---|---|---|---|---|
| ChatGPT (web, mobile) | Nothing documented | n/a | Not published | learn.chatgpt.com image generation |
| Gemini app (Nano Banana 2) | Nothing documented; download tier is plan-gated | n/a | 1K download, 2K on a Google AI plan | Gemini Apps Help |
OpenAI Image API (gpt-image-2) | size | Pixels, 1536x1024, or auto | auto | Image generation guide |
| Gemini API (Nano Banana) | aspect_ratio and image_size in response_format | Ratio string plus 1K / 2K / 4K | Input image, else 1:1 at 1K | ai.google.dev image generation |
| Midjourney (web, Discord) | --ar, plus --hd / --sd | Whole-number w:h, no decimals | 1:1 | Aspect Ratio |
Kling image, /v1/images/generations | aspect_ratio, resolution | 8 ratio strings; 1k / 2k | 16:9, 1k | Kling image generation |
Kling image, /v1/images/omni-image | aspect_ratio, resolution | Adds auto and 4k | auto, 1k | Kling omni image |
| Kling video 3.0 / 3.0 Omni | settings.aspect_ratio, settings.resolution | 16:9 / 9:16 / 1:1; 720p / 1080p / 4k | 16:9, 720p | Kling text to video |
| Veo 3.1 (Gemini API) | aspectRatio, resolution | 16:9 or 9:16 only | 16:9, 720p | Gemini API Veo |
Runway API, /v1/text_to_image | ratio | Pixel pair such as 1920:1080, per model | Required, no default | Runway API reference |
| xAI Grok Imagine Image 2.0 | aspect_ratio, resolution | Ratio strings, decimals allowed; 1k / 2k | auto, 1k | docs.x.ai image generation |
| Stability AI (Core, Ultra) | aspect_ratio only | One of nine enum values | 1:1 | Stability API reference |
| Ideogram 4.0 | resolution only | WIDTHxHEIGHT presets | Not published | Ideogram 4.0 generate |
Two things fall out of that table immediately. Three surfaces express size as pixels, five as a ratio string, one as a pixel pair that looks like a ratio, and two document no control at all. And the same field name means different things: Runway's ratio takes 1920:1080, while Veo's aspectRatio takes 16:9 and rejects everything except that and 9:16.
Why do the supported ratios differ between a vendor's app and its API?
Because they are different products with different schemas, and the app is usually the thinner one.
OpenAI is the clearest example. Its ChatGPT image generation documentation contains zero occurrences of "aspect", "portrait", "landscape", "square" or "resolution". The nearest thing to guidance is a bullet telling you to "Add framing, dimensions, lighting, colors, or materials when they matter", which is prompt advice, not a control. The same page notes that built-in image generation uses gpt-image-2 under the hood, and that model's API guide does expose a size field accepting "any resolution" within four published constraints. Same model, one surface with a dial and one without.
Google splits the same way. The Gemini Apps help article for image generation names no ratio control anywhere, and its only dimension statement is a plan gate: "Download images at at 2K resolution with a Google AI plan or at 1K without an AI plan" (the doubled "at" is Google's). Meanwhile the Gemini API publishes full resolution tables per model.
Even one vendor's own API versions disagree. Ideogram's 3.0 generate endpoint accepts both resolution and aspect_ratio. Its 4.0 endpoint accepts only resolution, and the page contains no occurrence of aspect_ratio at all. A script that worked on v3 and sets aspect_ratio on v4 is sending a field the endpoint does not document.
Runway makes the per-model split explicit in its own words. Its documentation index states that "Request bodies on generation endpoints are discriminated unions keyed on model, so the valid ratio, duration, and optional fields depend on which model is selected." On the single /v1/text_to_image endpoint, ten models each publish a different allowed list. gemini_2.5_flash starts at 1024:1024; gpt_image_2 has no 1024 option at all and starts at 1920:1088; seedream5_pro offers auto_1k and auto_2k tiers that no other model on the endpoint has.
Why does changing the resolution change my aspect ratio, or force a duration?
Because on several surfaces those settings are coupled, and the coupling is documented rather than emergent.
Midjourney couples ratio to quality tier. Its Version article, updated July 24, 2026, publishes a compatibility chart whose "Max. Aspect Ratio" row reads "14:1" for V6 and V7, and "14:1 (4:1 for HD)" for V8.1 and V8.2. So a banner at 10:1 is available in standard definition and not in HD, on the same model, at the same time. That article also gives the pixel table by way of its Upscalers page: in V8.2, 1:1 renders 1024x1024 SD and 2048x2048 HD, 4:3 renders 1232x928 and 2464x1856, 2:3 renders 896x1344 and 1792x2688, 16:9 renders 1456x816 and 2912x1632. Those four ratios are the only ones Midjourney publishes pixel dimensions for. Anything else you have seen quoted was calculated by somebody, not sourced.
Google couples ratio to model. Reading the resolution tables on the Gemini API image page: Gemini 3.1 Flash Image publishes fourteen ratios including 1:4, 1:8, 4:1 and 8:1, at 512px, 1K, 2K and 4K. Gemini 3.1 Pro Image publishes ten, dropping every extreme ratio and the 512px column entirely. Gemini 2.5 Flash Image publishes ten ratios at 1K and nothing above it. So the same aspect_ratio: "8:1" is valid on one Gemini image model and absent from the next one up.
Veo couples resolution to duration. The Gemini API's Veo parameter table, last updated July 30, 2026, documents durationSeconds as "4", "6", "8", and adds: "Must be 8 when using extension, reference images or with 1080p and 4k resolutions." The resolution row repeats it, marking both 1080p and 4k as "only supports 8s duration". Picking 1080p therefore silently removes your 4 and 6 second options.
| Feature | Midjourney V8.2 | Gemini API image | OpenAI gpt-image-2 | Veo 3.1 |
|---|---|---|---|---|
| Ratio is set by a parameter, not prompt text | ||||
| An exact pixel size can be requested | ||||
| Max ratio changes with the quality tier | Yes, 14:1 SD vs 4:1 HD | Yes, 8:1 on 3.1 Flash, 21:9 on 3.1 Pro | No, a flat 3:1 cap | No, 16:9 and 9:16 only |
| Resolution constrains another setting | HD cannot be upscaled further | 3.1 Flash Lite is 1K only | Above 2560x1440 is experimental | 1080p and 4k force 8 seconds |
| Highest documented output | 2048px HD | 4K | 3840px long edge | 4k |
| Value formatting is documented to matter | Yes, no decimals in --ar | Yes, uppercase K required | Yes, edges must be multiples of 16 | Not published |
Why does my ultra-wide request come back cropped or rejected?
Usually because it exceeded a published cap that nothing in the interface told you about.
OpenAI publishes the tightest set. Its image guide states that gpt-image-2 "accepts any resolution in the size parameter when it satisfies the constraints below", then lists four: the maximum edge must be 3840px or less, both edges must be multiples of 16px, the long-edge-to-short-edge ratio "must not exceed 3:1", and total pixels must sit between 655,360 and 8,294,400. That 3:1 rule quietly makes 21:9 impossible on this model, since 21:9 is 2.33:1 (fine) but a 4:1 banner is not. It also means an innocent-looking 1000x1000 fails, because 1000 is not a multiple of 16.
Midjourney publishes a softer version. Its Aspect Ratio article warns that "--ar cannot contain decimals. Use 139:100 instead of 1.39:1", that "Some aspect ratios may be slightly changed when upscaling", and that "Extremely wide and tall aspect ratios are experimental and may produce unpredictable results". xAI takes the opposite position on decimals: its image generation docs list 19.5:9 and 9:19.5 as supported values for modern iPhone displays. The same string is invalid on one surface and a first-class option on another.
Stability AI removes the question entirely. Its API reference exposes aspect_ratio with a fixed enum of nine values, default 1:1, and no width or height parameter at all. The output size is a per-service constant: the Ultra endpoint documents "The resolution of the generated image will be 1 megapixel. The default resolution is 1024x1024", and the Core endpoint documents 1.5 megapixels. You choose a shape; the service chooses the pixels.
Does "4K" mean generated at 4K or upscaled to it?
Both, depending on the surface, and vendors are reasonably clear about which they mean if you read the right page.
Native generation is what the Gemini API does. Its 4K column is a generation setting: "Gemini 3 image models generate 1K images by default but can also output 2K, 4K, and 512px", set through image_size in the request. Veo's 4k resolution value works the same way, at the cost of the duration lock described above.
Upscaling is what Midjourney does. Its Upscalers article explains that in V8.2 "your SD images start at 1024 x 1024px (using the default aspect ratio). You can then use the Creative and Subtle upscalers to bump up your images to 2048 x 2048px", that both upscalers "double the size of your original image", and that the Creative upscaler "will change your image a bit as it adds new details". The same page notes that "HD images generate at 2048 x 2048px automatically, and currently cannot be upscaled further", which is why a 2K HD render has no path to 4K inside Midjourney.
There is a third case worth knowing about, because it silently shrinks work you already have. Midjourney's Version article warns that "Using any of our inpainting or outpainting tools (Pan, Zoom Out, Edit/Vary Region) on HD images will downscale the resulting images to SD", and that you then have to re-upscale to get back to HD resolution. If a 2048px image came back at 1024px after an edit, that is the documented reason.
Will the model quietly substitute a different ratio than the one I asked for?
Not as an undocumented fallback, in anything I could verify. What vendors do document is inheritance and explicit auto modes, and those are easy to mistake for the model overruling you.
Google's default is inheritance: without an explicit setting, the model "matches the output image size to that of your input image". xAI's default is auto, which its docs describe as letting "the model pick the best ratio for the prompt", and for edits, "By default, the output aspect ratio follows the first input image." Kling's omni-image endpoint defaults aspect_ratio to auto, described as choosing "intelligently aspect ratio of the generated image based on incoming content". Runway offers adaptive with a stated restriction: "Use adaptive only when image or video references are provided; text-only requests require a concrete ratio."
Every one of those is a default you can turn off by setting the field. None is a documented case of a vendor snapping an unsupported ratio to the nearest supported one. So if your request genuinely came back at a different ratio than the value you sent, look at your wrapper, SDK or template before concluding the model ignored you. The broader diagnostic habit that fixes bad prompts applies here: verify the request that actually left your machine.
How do I request a specific size on each surface?
Copy the block for your surface. Every parameter name and value below appears in the vendor documentation linked in the table above.
Midjourney, web or Discord. Parameters go at the end, after a space, with no punctuation:
a rain-soaked Tokyo alley at night, neon signage --ar 16:9
a rain-soaked Tokyo alley at night, neon signage --ar 9:16
a rain-soaked Tokyo alley at night, neon signage --ar 16:9 --hd
a rain-soaked Tokyo alley at night, neon signage --ar 16:9 --sd
Midjourney, deriving a ratio from pixel dimensions you already have. The Aspect Ratio article's own worked example: enter --ar 1920:1080 and Midjourney simplifies it to 16:9. Decimals are rejected, so convert them:
product hero on seamless white --ar 1920:1080
poster layout, 8.5 by 11 inches --ar 85:110
cinema title card --ar 139:100
Midjourney, the four formatting mistakes its Parameter List article publishes side by side. Each of these is documented as wrong:
vibrant California poppies--ar 2:3 # no space before the dashes
vibrant California poppies - - ar 2:3 # extra space between the dashes
vibrant California poppies --ar 2:3, # punctuation in the parameter
vibrant California --ar 2:3 poppies # prompt text after the parameter
vibrant California poppies --ar 2:3 # correct
Gemini API, Nano Banana, REST. The ratio and size live under response_format, not in the prompt:
curl -s -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
-H "x-goog-api-key: $GEMINI_API_KEY" \
-H 'Content-Type: application/json' \
-d '{
"model": "gemini-3.1-flash-image",
"input": "An isometric cutaway of a coffee roastery",
"response_format": {
"type": "image",
"aspect_ratio": "16:9",
"image_size": "2K"
}
}'
Gemini API, Python, and the case rule. The docs state: "You must use an uppercase 'K' ... Lowercase parameters (e.g., 1k) will be rejected."
# rejected
response_format={"type": "image", "aspect_ratio": "16:9", "image_size": "2k"}
# accepted
response_format={"type": "image", "aspect_ratio": "16:9", "image_size": "2K"}
Gemini API, an extreme ratio that only one model in the family accepts:
interaction = client.interactions.create(
model="gemini-3.1-flash-image", # 8:1 is published for Flash
input="A panoramic mountain ridgeline at dawn",
response_format={"type": "image", "aspect_ratio": "8:1", "image_size": "1K"},
)
# gemini-3.1-pro-image does not publish 1:4, 1:8, 4:1 or 8:1
OpenAI Image API, gpt-image-2. The field is size, in pixels:
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":"A brushed-steel espresso machine","size":"1536x1024"}'
OpenAI Image API, the four published constraints, shown as failures and fixes:
"size": "1000x1000" # fails: edges must be multiples of 16
"size": "1024x1024" # ok
"size": "4096x2304" # fails: max edge is 3840px
"size": "3840x2160" # ok, 4K landscape
"size": "4000x1000" # fails: long-to-short ratio must not exceed 3:1
"size": "3072x1024" # ok, exactly 3:1
"size": "512x512" # fails: total pixels must be >= 655,360
"size": "1024x1024" # ok
xAI, Grok Imagine Image 2.0. Ratio and resolution are separate fields, and decimals are allowed here:
curl -X POST https://api.x.ai/v1/images/generations \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $XAI_API_KEY" \
-d '{
"model": "grok-imagine-image-2.0",
"prompt": "A lighthouse in a storm",
"aspect_ratio": "19.5:9",
"resolution": "2k"
}'
Kling image, the standard endpoint. Note the default is 16:9, not square, and the resolution value is lowercase:
curl -X POST https://api-singapore.klingai.com/v1/images/generations \
-H "Authorization: Bearer $KLING_KEY" -H "Content-Type: application/json" \
-d '{"model_name":"kling-v3","prompt":"A koi pond from above","aspect_ratio":"21:9","resolution":"2k"}'
Kling image, the omni endpoint, which is the only one publishing 4k:
curl -X POST https://api-singapore.klingai.com/v1/images/omni-image \
-H "Authorization: Bearer $KLING_KEY" -H "Content-Type: application/json" \
-d '{"prompt":"A koi pond from above","aspect_ratio":"21:9","resolution":"4k"}'
Kling video 3.0 Omni. The dimension fields sit under settings:
{
"prompt": "A drone rises over terraced rice fields at sunrise",
"settings": { "resolution": "4k", "aspect_ratio": "16:9", "duration": 15 }
}
Veo 3.1 via the Gemini API. Only two ratios exist, and the resolution choice sets the duration:
operation = client.models.generate_videos(
model="veo-3.1-generate-preview",
prompt="A drone rises over terraced rice fields at sunrise",
config=types.GenerateVideosConfig(aspect_ratio="9:16", resolution="1080p"),
)
# durationSeconds must be "8" at 1080p and 4k. 4 and 6 exist only at 720p.
Runway, /v1/text_to_image. The value is a pixel pair and the legal list is per model:
{ "model": "gen4_image", "promptText": "A neon ramen bar", "ratio": "1920:1080" }
{ "model": "gpt_image_2", "promptText": "A neon ramen bar", "ratio": "2560:1440" }
{ "model": "seedream5_pro", "promptText": "A neon ramen bar", "ratio": "auto_2k" }
Stability AI. A ratio, and no size field to set:
curl -f -X POST https://api.stability.ai/v2beta/stable-image/generate/ultra \
-H "Authorization: Bearer $STABILITY_KEY" -H "Accept: image/*" \
-F prompt="A brutalist library interior" \
-F aspect_ratio="21:9"
Ideogram 4.0. There is no aspect_ratio field; pick a resolution preset:
curl -X POST https://api.ideogram.ai/v1/ideogram-v4/generate \
-H "Api-Key: $IDEOGRAM_KEY" \
-F text_prompt="A vintage travel poster for Reykjavik" \
-F resolution="1440x2560"
ChatGPT or the Gemini app, where no control is documented. State the shape as a compositional instruction and expect to crop, rather than expecting a parameter to exist:
Create a wide, horizontal editorial illustration of a coffee roastery.
Compose it for a widescreen banner: keep the subject centred with generous
empty space to the left and right, and nothing important near the top or
bottom edges. I will crop this to 16:9, so leave room for that crop.
What should I check first, in order?
- Confirm the surface has a control at all. If it is ChatGPT or the Gemini app, it does not, per the pages linked above.
- Confirm you set the field, not the prompt text. This resolves most cases.
- Confirm the value is legal for that exact model, not the vendor generally. Midjourney's
--arreference covers the version-by-version detail there, and our version flags reference covers which model you are actually on. - Confirm the quality tier does not cap it. HD versus SD in Midjourney, Flash versus Pro in Gemini.
- Read back the dimensions the API returned rather than trusting the ones you sent.
If the shape is right but the picture is not, that is a different problem with a different fix. The wrong subject appearing is attribute binding, and prompts that produce nothing like what you pictured usually fail on specificity, not on dimensions. Size is the one failure on that list that is almost never about your wording.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An Account