Aspect Ratios and Platform Specs for AI Video (2026 Reference)

TL;DR: Aspect ratio is a request parameter, never prose, and the menu is short: Veo offers only 16:9/9:16, Grok Imagine offers seven, most others sit between three and six. Platforms want mostly overlapping but not identical things: YouTube wants 16:9, TikTok/Reels/Stories want 9:16, LinkedIn and X take four ratios each. Generate at the model's native ratio, then reframe per destination.

One clarification before the tables. Prompt Architects writes the prompt, including the field that sets the ratio; it doesn't render the video, and it doesn't crop or reframe a finished clip. Everything below is what to type into that field per vendor, and what to do with the output once you have it.

What Aspect Ratios Can Each AI Video Model Actually Output?

A short list per vendor, read from each vendor's own current API documentation, all accessed September 2, 2026 unless noted otherwise.

Sources: Veo on Gemini API · Sora video generation guide · Kling 3.0 Omni text-to-video reference · Runway API reference · BytePlus ModelArk video generation task reference · xAI video generation docs · Vidu text-to-video reference · Alibaba Cloud Wan 2.7 text-to-video reference · Luma Agents video generation guide · MiniMax video generation create-task reference.

Veo is the outlier at the narrow end. Google's Gemini API page for Veo 3.1 lists exactly two values for aspectRatio, 16:9 and 9:16, across every current Veo variant, from the full model down to 3.1 Lite. There is no square option and no ultrawide option on that surface, so a request for anything else on Veo has to be handled outside the model, not inside the parameter. If you're building a full Veo request rather than just the ratio field, our Veo 3 prompt structure guide covers the rest of it, and post 234 covers the duration field this ratio is often paired with.

Sora is the other narrow case, and the one with an expiration date attached. OpenAI's own size options resolve to the same two shapes, 1280×720 (landscape) and 720×1280 (portrait), with sora-2-pro adding 1920×1080 and 1080×1920 at higher resolution. It's not worth building around for long: OpenAI's deprecations page, first checked for this project on August 26, 2026, schedules the entire Sora API for removal on September 24, 2026, with no replacement model listed. Post 192 covers where those prompts go instead.

Grok Imagine sits at the opposite end. xAI's own reference lists seven values, each with a suggested use case attached: 1:1 for social posts and thumbnails, 16:9/9:16 for widescreen and mobile stories, 4:3/3:4 for presentations and portraits, 3:2/2:3 for photography-style framing. On image-to-video the output defaults to the input image's own ratio; setting aspect_ratio explicitly overrides that and stretches the source image to fit the requested shape.

Which Models Actually Inherit the Input Image's Ratio on Image-to-Video?

Fewer than you'd expect, and the ones that don't publish an aspect ratio field for image-to-video at all are the ones worth flagging, because there's nothing to override. Seedance's first-frame and first-and-last-frame image-to-video tasks automatically preserve the input image's ratio, per BytePlus's own task-creation reference. Its separate reference-image mode, though, lets you specify a ratio independently instead of inheriting one. Wan 2.7's image-to-video reference states plainly that the output ratio "is determined by the input material… but is not guaranteed to match exactly", since Alibaba Cloud still rounds width and height to multiples of 16 for encoding.

Kling's image-to-video endpoint documents no aspect_ratio field whatsoever: the only ratio constraint published anywhere on that page is on the input image, which must fall between 1:2.5 and 2.5:1. Vidu's img2video and start-end2video endpoints are the same: no aspect_ratio field exists, so frame shape comes from whatever image you send in.

What Aspect Ratio Does Each Platform Actually Want in 2026?

This is a separate question from what a model can output, and the two lists were never designed to match each other.

Two things are worth reading past the table. First, YouTube's own organic-upload Shorts page never states a numeric ratio at all: it only says "square or vertical". The 9:16 figure most guides repeat comes from Google's ads documentation for the Shorts placement, not the creator-upload page, which is a real distinction worth naming rather than collapsing into one number.

Second, LinkedIn and X both quietly expanded their accepted ratios this year rather than converging on one. LinkedIn's help center lists a minimum aspect ratio of 9:16 (0.563) and maximum of 16:9 (1.778), with 1:1 and 4:5 as the two ratios in between: four live options, with no single one marked as the platform default. X's own creative specs describe 4:5 and 2:3 as newly supported expanded aspect ratios, on top of the older 1:1, 1.91:1, 16:9 and 9:16. Whatever you generate, check the count is still current before you build a template around it, since these pages change.

Does YouTube Crop Vertical Video Thumbnails to 4:5?

Yes, and it's documented plainly, but it's specifically the custom thumbnail, not the video frame itself. YouTube's own help center states: "Vertical videos with 16:9 custom thumbnails will be replaced by an auto-generated 4:5 thumbnail on the home, explore, and subscription pages. Your custom thumbnail will still appear on the watch feed, watch history, and non-mobile platforms."

That's a narrower claim than "YouTube crops vertical video to 4:5": it applies to vertical, non-Shorts uploads that use a 16:9 custom thumbnail, and only on three specific surfaces. But the practical consequence is the same one you'd draw from a full-frame crop: any face, logo or line of text sitting near the left or right edge of that thumbnail gets clipped on exactly the feeds where most casual browsing happens. YouTube's own thumbnail spec separately recommends 9:16 thumbnails for Shorts and 16:9 for standard video. Our thumbnail prompt generator builds both from one brief so you're not designing the crop twice.

Why Don't Model Outputs and Platform Specs Line Up?

Because they were built by two different sets of people solving two different problems, on two different timelines. Video model vendors publish a request parameter shaped by what their architecture can render efficiently: Veo's two options and Grok Imagine's seven weren't chosen with TikTok's help page open. Platforms publish a recommendation shaped by how their feed is laid out on a phone screen, which changes as the product changes, not as models ship.

The overlap that does exist is mostly luck: 16:9 and 9:16 happen to be common to both lists because landscape and portrait video predate generative models entirely. But the moment you look at 21:9, 4:5, 1.91:1 or 3:2, the two lists stop agreeing: Seedance and MiniMax both output 21:9, but no platform in the table above lists 21:9 as recommended for anything; LinkedIn and Instagram both want 4:5-adjacent ratios, but only Seedance publishes 21:9-through-4:3 output and neither Kling nor Veo can be asked for 4:5 directly at all.

The practical conclusion is the one in the brief: pick the model ratio the vendor actually documents, generate there, and treat the platform ratio as a second, separate step, not something the model's aspect_ratio field is going to solve for you in one call.

Which Crops Are Safe, and Which Ones Destroy a Shot?

It depends entirely on how much width or height the crop has to remove, and that's arithmetic, not opinion.

Cropping 16:9 down to 4:5 (the ratio YouTube auto-generates for vertical thumbnails, and one LinkedIn and Instagram both use) removes a moderate slice: going from a 1.78:1 frame to a 0.8:1 frame at constant height keeps about 45% of the original width. That's survivable for a composition with one centered subject and breathing room on both sides, which is exactly why keeping the subject and any text inside the center third of the frame is the standard advice for this crop.

Cropping 16:9 down to 9:16 is a different order of loss. Holding height constant, the surviving width is (9/16) ÷ (16/9) ≈ 0.316 of the original: meaning a straight center-crop keeps roughly 32% of the frame's width and throws away the rest. A wide two-shot, a landscape establishing shot, or a caption sitting near either edge does not survive that; it either gets cut in half or vanishes entirely. The fix isn't a smarter crop; it's composing the original shot with that outcome already in mind (subject dead-center, nothing load-bearing outside the middle third) or, better, asking the model for 9:16 directly when it publishes that ratio, which Kling, Seedance, Grok Imagine, Vidu, Wan, Luma Ray and MiniMax all do.

The reverse direction has its own trap. Going from a vertical 9:16 generation to a landscape platform slot can't be solved by cropping at all without losing most of the frame's height: the honest options are padding (letterboxing with a solid or blurred background, which is visible and looks unfinished) or a generative reframe/outpaint pass in an editor that extends the sides rather than cutting the top and bottom. Neither is free, which is the actual argument for generating at the ratio you need in the first place rather than fixing it downstream.

Copy-Paste Prompts With the Ratio Parameter Set Correctly

The prompt text never carries the ratio — every vendor checked here reads it from a separate field, not from words like "vertical" or "16:9" in the prompt itself. Ratio is one field among several; the seven-part video prompt anatomy covers where it sits alongside subject, camera and lighting. Here's the field, set to 9:16, for each:

// Veo 3.1, Gemini API
{ "instances": [{ "prompt": "..." }],
  "parameters": { "aspectRatio": "9:16", "durationSeconds": "8" } }

# 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}}'

// Runway Gen-4.5, image-to-video (colon form, width:height)
{ "model": "gen4.5", "promptImage": "...", "promptText": "...", "ratio": "720:1280" }

// Seedance 2.5, BytePlus ModelArk
{ "model": "dreamina-seedance-2-5-260628",
  "content": [{ "type": "text", "text": "..." }],
  "ratio": "9:16", "duration": 10 }

# Grok Imagine Video 1.5
response = client.video.generate(
    prompt="...", model="grok-imagine-video-1.5",
    aspect_ratio="9:16", resolution="720p", duration=10,
)

# Vidu Q3, text2video
curl -X POST https://api.vidu.com/ent/v2/text2video \
  -H "Authorization: Token $VIDU_API_KEY" -H "Content-Type: application/json" \
  -d '{"model":"viduq3-pro","prompt":"...","aspect_ratio":"9:16","duration":8}'

# Wan 2.7, text-to-video
curl --location 'https://{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com/api/v1/services/aigc/video-generation/video-synthesis' \
  -H "Authorization: Bearer $DASHSCOPE_API_KEY" -H 'Content-Type: application/json' \
  -d '{"model":"wan2.7-t2v-2026-06-12","input":{"prompt":"..."},"parameters":{"resolution":"1080P","ratio":"9:16","duration":8}}'

Every one of these fails differently if you get the field name wrong. Runway wants a colon-separated pixel-style string (720:1280), not a plain ratio (9:16): sending the wrong shape to the wrong vendor is the single most common way this parameter goes ignored rather than rejected outright, because several of these APIs validate loosely on unrecognized fields instead of erroring.

None of this is exotic; it's a lookup you'll do again the next time a vendor ships a version bump or a platform quietly widens its accepted range. The habit that survives every update is the same one this whole page is built on: generate at whatever ratio the model actually documents, ship that file wherever it fits, and treat the platform crop as a deliberate design decision made before you shoot, not a rescue job done after.