9:16 aspect ratio in pixels: 1080 × 1920

9:16 resolutions in pixels

Every resolution below is 9:16. What changes is the pixel count, not the proportion.

You will find longer tables elsewhere, padded out with phone screen sizes like 1125 × 2000 or 1284 × 2282. Those are handset resolutions, not delivery formats — and most of them aren't even 9:16 (an iPhone Pro Max screen is about 9:19.5). Don't export to them. Our own encoder offers 1080 and 720 and nothing else, on purpose.

What cropping a 16:9 to 9:16 really costs

Here is the sum almost nobody does. Take a 1920 × 1080 video. The largest 9:16 crop that fits inside it keeps the full height, 1080 px, and is 1080 × 9/16 = 607.5 px wide. That is 656,100 pixels out of the original 2,073,600. 31.6%. The other 68.4% goes in the bin.

Now the uncomfortable part: 607.5 px of width is below the 1080 the standard wants. Publishing at 1080 × 1920 means upscaling ×1.78. You are stretching pixels that were never recorded. That is why your vertical looks mushy even though the original was Full HD.

Look at the “Kept” column. Always 31.6%, at 720p and at 4K alike. That isn't a coincidence: the percentage depends only on the ratio, never on the resolution. Cropping 16:9 to 9:16 costs 68.4% of the picture every time. A 4:3 source gets off lighter (42.2%) because it was less wide to begin with.

Try it with your dimensions

Put in the real size of your video. Everything you see is arithmetic on those two numbers.

Why 607.5 becomes 608

607.5 isn't a whole number of pixels. There is no half pixel. So it has to be rounded — and not to just anything: H.264 with 4:2:0 chroma subsampling (yuv420p, the thing every device plays) works in 2 × 2 pixel blocks, so it demands even dimensions. Hence 607.5 → 608, not 607.

If you have ever watched ffmpeg spit out width not divisible by 2 and die, this is why. In our own code the output size calculation ends in Math.round(x / 2) * 2 for that exact reason. A boring line that prevents a failed export.

“Zoom to 175% and reposition” is not an answer

Every guide on this subject ends the same way: zoom in, drag the frame onto your subject, export. That works for exactly one kind of shot — the one where the subject never moves. A locked-off talking head, centred, tripod. Fine.

Anything else and a static crop fails halfway through the clip. The speaker leans out of frame. Two people sit 1.2 m apart and only one fits in 608 px. The camera pans. You end up cutting the clip into pieces and re-cropping each piece, which is where an afternoon goes.

So our converter moves the crop window instead. Concretely: worker/track.py runs OpenCV's bundled Haar cascade over the frames, smooths the resulting centre path (raw detections jitter, and a jittery crop is worse than a static one), and hands ffmpeg a sendcmd script that drives the crop window over time. The geometry is unchanged — still 31.6% — but the 31.6% follows the face.

9:16 specs by platform

All four publish at 1080 × 1920. What differs is duration and weight.

Two warnings about this table. First: the only figure here I can point at official documentation for is Shorts, 3 minutes since 15 October 2024. The rest comes from each platform's help centre and changes without notice: these are the values as of July 2026. Second: you won't find an “ideal duration” column here. Very precise numbers circulate for that (“21–34 s”) with no traceable source, and I am not going to repeat them. What is a spec is in the table. How long your video should be depends on your niche.

The export settings I actually use

No mystery, and no made-up bitrate table. These are literally the parameters the make-vertical.com encoder exports every video with:

-c:v libx264 -preset veryfast -crf 21 -pix_fmt yuv420p
-c:a aac -b:a 160k
-movflags +faststart

• CRF 21 instead of a fixed bitrate. You pin the quality and let the size follow: a static shot comes out small, a busy one comes out bigger. A fixed bitrate does the exact opposite, which is the opposite of what you want. 18 to 23 is the sane range; below 18 the file balloons and the platform re-encodes it anyway.
• yuv420p, always. Without it, some phones simply won't open the file.
• +faststart. Moves the MP4 index to the front so playback can start before the file finishes downloading. Costs nothing, noticeable on upload.
• AAC 160 kbps. Plenty for speech and background music. 320 kbps on a TikTok is throwing away megabytes.
• preset veryfast. Here I am making a trade: server speed in exchange for a few extra megabytes versus slow. At a fixed CRF the visual quality doesn't change, only the file size. If you're exporting on your own laptop and aren't in a hurry, use slow.

Keep going