YouTube Shorts Video Settings That Survive the Re-Encode

You exported a Short at maximum quality, uploaded it, and it came back soft and blocky on a phone. Then you did it again for the next 29 videos in the queue, by hand, in an editor. Most Shorts spec tables give you the dimensions and stop there.

Quick answer: The YouTube Shorts video settings that survive YouTube's re-encode are 1080x1920 (9:16), H.264 High profile in an MP4 with yuv420p, roughly 8 Mbps at 30 fps or 12 Mbps at 60 fps, AAC-LC audio at 48 kHz stereo, -movflags +faststart, and a runtime under the 3-minute Shorts limit. You can hit all of that with a single ffmpeg command per file. If you'd rather not host an encoder or babysit a render queue for 30 uploads a week, send the source to FFmpeg Micro and get the Shorts-ready master back as one API call.

Your upload bitrate is a suggestion. Your pixel geometry is not.

Conventional wisdom says to upload the highest bitrate your machine can produce, and YouTube will preserve the quality. Most exports do come out looking worse than the master, so the advice feels right. But the cause isn't a low bitrate. It's that YouTube re-encodes every upload into its own VP9 and AV1 ladders, so your 40 Mbps file and your 10 Mbps file both get thrown away and rebuilt.

What actually carries through is everything the transcoder can't fix: the frame size, the aspect ratio, chroma subsampling, frame-rate stability, and whether your text sits under the interface. Bitrate above roughly 10 Mbps buys you almost nothing on a 1080x1920 clip. Feeding the transcoder clean, correctly framed pixels buys you everything.

The encode ladder for YouTube Shorts

A Shorts master is a 1080x1920 H.264 MP4 with progressive constant-frame-rate video and 48 kHz stereo AAC. YouTube's published upload encoding guidance asks for a closed GOP at half the frame rate, and Shorts adds vertical framing and the 3-minute cap.

A 60-second Short at 8 Mbps video plus 192 kbps audio lands at about 61 MB. At 12 Mbps for 60 fps, about 91 MB. Neither is near YouTube's 256 GB upload ceiling, so there's no reason to shave the bitrate down.

Two of those flags matter more than the rest. yuv420p makes the file decodable on every phone, and +faststart moves the moov atom to the front so playback and processing don't need the whole file first. If you've ever shipped an MP4 that refused to play, those same four encoder flags are usually the fix.

The loudness line is the one creator guides skip. YouTube normalizes playback to roughly -14 LUFS, so a master at -9 gets turned down, and everything you layered under it goes down with it. Normalize on your side and what you hear in the export is what viewers hear.

One command that handles any source aspect ratio

A reusable Shorts command has to survive 16:9 screen recordings, 1:1 exports, 4:5 UGC clips, and phone footage that's already vertical. The force_original_aspect_ratio option on the scale filter fits or fills without knowing the input dimensions.

Padding keeps the entire frame and adds bars:

ffmpeg -i input.mov \
  -vf "scale=1080:1920:force_original_aspect_ratio=decrease,\
pad=1080:1920:(ow-iw)/2:max(0\,(oh-ih)/2-140):black,\
setsar=1,fps=30,format=yuv420p" \
  -c:v libx264 -profile:v high -level 4.0 -preset slow \
  -b:v 8M -maxrate 10M -bufsize 16M \
  -g 15 -keyint_min 15 -sc_threshold 0 \
  -c:a aac -ar 48000 -ac 2 -b:a 192k \
  -af "loudnorm=I=-14:TP=-1.5:LRA=11" \
  -movflags +faststart -t 179 shorts/output.mp4

The -140 in the pad offset lifts the video 140 px above center so the frame doesn't sit under the title and description overlay. The max(0\,...) guard keeps the command reusable: without it, an input that's already 1080x1920 produces a negative pad offset and FFmpeg errors out.

Cropping fills the frame instead, at a real cost. Going from 1920x1080 to 9:16 keeps 607 px of the original 1920 px width, which is 31.6% of the frame.

-vf "scale=1080:1920:force_original_aspect_ratio=increase,crop=1080:1920,setsar=1,fps=30,format=yuv420p"

Use crop=1080:1920:(iw-1080)/2+X:0 to shift the crop window when your subject isn't centered, common with interview footage framed to one side.

Blurred backdrop instead of black bars

A blurred fill reads better than black bars on a 16:9 source and costs one extra filter chain. The background is the same clip scaled to fill and blurred, with the sharp version on top.

ffmpeg -i input.mp4 -filter_complex \
"[0:v]split=2[bg][fg];\
[bg]scale=1080:1920:force_original_aspect_ratio=increase,crop=1080:1920,gblur=sigma=40[bgb];\
[fg]scale=1080:1920:force_original_aspect_ratio=decrease[fgs];\
[bgb][fgs]overlay=(W-w)/2:(H-h)/2-140,setsar=1,fps=30,format=yuv420p[v]" \
  -map "[v]" -map 0:a -c:v libx264 -profile:v high -preset slow -b:v 8M \
  -c:a aac -ar 48000 -ac 2 -b:a 192k -movflags +faststart out.mp4

Odd dimensions are where this breaks for a lot of people. The pad target here is fixed at 1080x1920, so you're safe, but compute dimensions from the source and you can land on an odd number and hit the classic height not divisible by 2 error.

Safe-area margins so the Shorts UI doesn't cover your text

The Shorts player draws its own chrome over your video: a right-hand column of like, comment, share, and remix buttons, and a bottom block with the channel handle, title, description, and sound attribution. YouTube doesn't publish exact pixel dimensions for these, so the numbers below come from measuring screenshots on a 1080x1920 frame and rounding outward.

That leaves a safe box of roughly 840x1300, from x=60 to x=900 and y=200 to y=1500. Any burned-in hook text, logo, or caption line that lands outside it gets covered on some devices.

Placing a hook inside the box with drawtext:

-vf "drawtext=fontfile=/usr/share/fonts/truetype/inter/Inter-Bold.ttf:\
text='Your export is 400 MB. Here is why.':\
fontsize=64:fontcolor=white:borderw=4:bordercolor=black@0.7:\
x=(w-text_w)/2:y=280"

Always pass an explicit fontfile. Leaving it to fontconfig is how a batch of 30 videos silently renders in DejaVu Sans instead of your brand font, which is a warning FFmpeg prints and then ignores.

Batching it for a publishing queue

Running the same command over a folder is a four-line shell loop, and four at once uses the cores you have. -preset slow on a 60-second 1080x1920 clip runs roughly at real time on a 4-core laptop, so a queue of 30 clips is a half-hour of a machine you can't use.

mkdir -p shorts
find raw -name '*.mp4' -print0 | xargs -0 -P 4 -I{} sh -c '
  ffmpeg -hide_banner -loglevel error -y -i "$1" \
    -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:max(0\,(oh-ih)/2-140),setsar=1,fps=30,format=yuv420p" \
    -c:v libx264 -profile:v high -preset slow -b:v 8M -maxrate 10M -bufsize 16M \
    -c:a aac -ar 48000 -ac 2 -b:a 192k -movflags +faststart -t 179 \
    "shorts/$(basename "$1")"
' _ {}

This is where the local approach stops scaling. A publishing queue that runs on a schedule needs a machine that's awake, an FFmpeg build with libx264 actually compiled in, and something watching for the job that dies at minute nine. If your pipeline already lives in n8n, Make, or Zapier, the reframe-and-encode step is one call to the FFmpeg Micro API with the source URL and the target aspect ratio. The same job is a resize-format blueprint if you'd rather point and click than write JSON. No encoder to install, no worker to keep alive, and the long-running job doesn't have to finish inside a workflow node's timeout. Teams running faceless video channels chain it straight into the caption and upload steps.

Common pitfalls

Most Shorts encoding problems come from the input, not the command. Variable frame rate is the biggest one: OBS and iOS both produce VFR files, and without -fps_mode cfr (which replaced the deprecated -vsync cfr in FFmpeg 5.1) the audio drifts out of sync a minute in.

When this is the wrong approach

An FFmpeg command is the right tool when the source is finished video and you only need to reformat and encode it. If your Short is text and stock images assembled from a script every morning, a template-driven rendering service will get you there faster, because you'd otherwise be rebuilding a layout engine in drawtext and overlay.

If you publish two Shorts a month, your editor's export preset is fine and this whole page is overhead. The math changes at roughly ten uploads a week, where manual export starts costing more than automation.

FAQ

What bitrate should I use for YouTube Shorts?

Use 8 Mbps for 1080x1920 at 30 fps and 12 Mbps at 60 fps, which matches YouTube's recommended upload bitrates for 1080p SDR. Going above about 15 Mbps is wasted, because YouTube re-encodes every upload into its own VP9 and AV1 ladders regardless of what you sent.

Does YouTube Shorts support 60 fps?

YouTube Shorts plays back 60 fps fine, and it's worth using for gameplay, sports, and fast camera motion. For talking-head and slideshow content, 30 fps at 8 Mbps looks identical and produces a file about a third smaller.

How long can a YouTube Short be?

A YouTube Short can run up to 3 minutes. Anything longer, or anything wider than square, publishes as a regular video, so trimming to 179 seconds avoids the edge where a 180.1-second file falls out of the Shorts format.

Should I crop or pad a 16:9 video for Shorts?

Crop when the subject is centered and the edges of the frame carry no information, because cropping 1920x1080 to 9:16 keeps only 31.6% of the original width. Pad, ideally with a blurred fill, when the framing matters or text near the edges would otherwise be cut off.

Why does my Short look soft after uploading?

A soft Short is almost always a resolution or frame-rate mismatch, not a bitrate problem. Upload at exactly 1080x1920 with constant frame rate and yuv420p, because upscaled sources, variable frame rate, and non-standard dimensions all force YouTube's transcoder into decisions that cost detail.

Point the API at a source URL, pick 9:16, and the encode ladder above comes back as a finished MP4 with the moov atom already at the front. The free tier is enough to run your next batch of 30 and compare it against your editor's export before wiring it into the queue.