A vertical video is not displayed the way you exported it. The platform draws a caption, a username, a follow button, a like-comment-share stack, a sound credit, a progress bar and - in an ad - a call-to-action bar, all on top of your frame. None of that is in your export, none of it appears in your editing timeline, and all of it appears on the viewer's phone.
The result is a specific and very common failure: an ad that looks well composed in review and has its subtitle sitting underneath a CTA button in the wild. It costs nothing to avoid and it is invisible until it has already run.
Generate inside the safe zone
siriusly.ai renders vertical natively and keeps captions inside the zone every platform leaves alone, so the same cut ships to all three.
Try it freeThe Master Format
Start from one master and derive everything else from it. For short-form vertical that master is:
| Property | Value | Why |
|---|---|---|
| Resolution | 1080 x 1920 | Universally accepted, matches phone displays, avoids upscaling |
| Aspect ratio | 9:16 | The only ratio that fills a vertical feed edge to edge |
| Frame rate | 30fps (or 24/25 if your source is) | Keep the source rate rather than converting; conversion adds judder |
| Video codec | H.264, yuv420p | Broadest compatibility; every platform re-encodes anyway |
| Audio | AAC, 128kbps or better, stereo | Audio is transcoded less aggressively than video |
| Colour | Rec.709, no HDR | HDR-to-SDR conversion on upload is unpredictable and often washes out |
The yuv420p detail is worth calling out because it bites people: some encoders default to a chroma subsampling that many players and pipelines silently reject or re-encode badly, producing a video that plays fine locally and looks wrong after upload.
Where the Interface Actually Sits
Exact pixel values shift as platforms redesign, so treat these as working margins to design against rather than as a permanent specification - and re-check them on a real device once a quarter:
| Region | Roughly | What sits there |
|---|---|---|
| Top | ~12% of height | Status bar, back arrow, page tabs, sound name |
| Bottom | ~20-35% of height | Caption text, username, CTA bar, progress bar |
| Right edge | ~15% of width | Like, comment, share, profile, sound disc |
| Left edge | ~5% of width | Caption text wrapping, occasional badges |
The bottom band is the one that varies most, and it varies for a reason that matters: an organic post has less chrome than a paid one, because an ad adds a call-to-action bar underneath everything else. That means a video that is safe organically can be unsafe as an ad on the same platform. If a cut will run in both places, design against the paid margin.
A Single Layout That Survives All Three
Rather than maintaining per-platform crops, it is far easier to compose once inside the intersection of the safe zones:
- Keep faces in the top-middle third. Vertically, roughly between 15% and 55% of the frame height. This is above the caption band and below the status bar on every platform.
- Keep captions between 55% and 75% of frame height. Below the face, above the bottom chrome. This is the band that survives everywhere.
- Keep everything meaningful inside the middle 80% horizontally. The right-edge action stack eats more width than people expect.
- Never place text in the bottom 20%. Not a logo, not a legal line, not a price. Something will cover it.
- Treat the top 12% as decoration only. Background, sky, room - nothing that has to be read.
The one-line version
On a 1080x1920 frame: faces between y=290 and y=1050, captions between y=1050 and y=1440, nothing readable above y=230 or below y=1540, and nothing important outside x=110 to x=970.
Compose to that and the same file ships to Reels, TikTok and Shorts, organic or paid, without a per-platform recut.
Checking a Cut Before It Runs
The fastest sanity check is to render the safe zone directly onto a copy of the video and look at it. One ffmpeg call draws the boxes:
ffmpeg -i input.mp4 -vf "\
drawbox=x=0:y=0:w=1080:h=230:color=red@0.35:t=fill,\
drawbox=x=0:y=1540:w=1080:h=380:color=red@0.35:t=fill,\
drawbox=x=970:y=0:w=110:h=1920:color=red@0.35:t=fill" \
-c:a copy safe_check.mp4Anything you need the viewer to read that is underneath a red box is a problem. This takes a few seconds and catches the entire class of error.
To confirm the file itself is the format you think it is:
ffprobe -v error -select_streams v:0 \
-show_entries stream=width,height,r_frame_rate,pix_fmt,codec_name \
-of default=noprint_wrappers=1 input.mp4And if a source arrived in the wrong shape - a horizontal clip, or a square one - the correct fix is almost never to stretch it. Pad it and keep the subject centred:
ffmpeg -i input.mp4 -vf "\
scale=1080:-2,\
pad=1080:1920:(ow-iw)/2:(oh-ih)/2:color=black,\
setsar=1" -c:a copy vertical.mp4Padding is honest but wastes the most valuable screen real estate on the platform. If the footage matters, generate it vertical in the first place - reframing a horizontal shot into 9:16 always throws away either the sides of the composition or the resolution.
Duration, and What the Platforms Reward
Length limits are generous everywhere now and are not the binding constraint. Retention is. Some practical notes:
- Shorter is not automatically better. A 30-second ad that holds attention outperforms a 12-second one that does not. Optimize for the retention curve, not the runtime.
- Loops matter more than they look. Short-form players replay automatically, and a cut that loops cleanly gets a second pass at the viewer for free. Ending on roughly the same framing you opened with is enough.
- Do not put the call to action only at the end. Most viewers never reach the end. If the offer only appears at second 28, most of the audience never saw it.
- Assume muted playback for the first second. Sound is on for many viewers but not all, and the ones with it off are deciding on the picture and the caption alone.
Captions Are Part of the Layout
Burned-in captions are effectively mandatory in a muted-first feed, and they are also the element most likely to collide with platform chrome, because the natural place to put a subtitle is exactly where the platform puts its own text.
Two rules keep them safe. Fix the vertical band - captions live in a defined stripe, not wherever the line happens to wrap - and cap the line count, because a caption allowed to grow to four lines will grow downward into the chrome. Two lines maximum, with the wrap decided at render time rather than by the player. The full mechanics, including the ASS layout that produces the word-by-word reveal, are in the captions guide.
Platform auto-captions are not a substitute. They are placed by the platform, styled by the platform, and frequently wrong on brand names - which is a particularly bad place to be wrong.
Common Mistakes
Reviewing on a desktop preview. The chrome is not in your export, so nothing looks covered until it is on a phone.
Fix: draw the safe zones onto a copy with one ffmpeg call, and review that. Takes seconds and shows exactly what is at risk.
Designing for the organic layout and running it as an ad. The CTA bar adds chrome the organic version does not have, and it lands directly on your subtitle line.
Fix: compose to the paid margin always. It costs a little vertical space and removes the whole category of problem.
Reframing horizontal footage to vertical. You lose either the composition or the resolution, and usually both.
Fix: generate or shoot vertical natively. Vertical is the delivery format; treating it as a crop of something else shows.
Letting captions wrap freely. A long sentence becomes four lines, and lines three and four are under the interface.
Fix: fix the caption band, cap it at two lines, and decide the wrap when you render rather than leaving it to the player.
FAQs
Is 4:5 still worth exporting?
For feed placements, yes - it occupies more vertical space than 1:1 while still fitting a scrolling feed. But it is a separate export for a separate placement, not a replacement for 9:16, and the safe-zone logic differs. If you only make one, make 9:16.
Should I export at higher than 1080x1920?
Only if your source genuinely has the detail. Platforms re-encode everything, and uploading an upscaled file gives the encoder more pixels of the same information to spend bitrate on. Native 1080x1920 is the sweet spot for most short-form.
Do the safe zones change by device?
Somewhat. Taller phones and different notch geometries shift the bands a little, which is another argument for designing against a conservative intersection rather than a per-platform pixel spec. The margins above already include some slack for this.
What about the first frame specifically?
It gets used as a thumbnail in some surfaces, so it is worth making sure it is a real frame rather than a fade-in from black, and that nothing important sits under where a play button might render. It is also, separately, the frame that decides whether anyone watches at all - the hook argument is in the piece on the first three seconds.
Can one file really run on all three platforms?
Yes, for the video itself, if it is composed to the intersection. What should not be shared is the copy, the thumbnail choice and the pacing - those are worth adapting per platform even when the render is identical.