{"id":1255,"date":"2026-08-12T09:49:01","date_gmt":"2026-08-12T02:49:01","guid":{"rendered":"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/"},"modified":"2026-08-12T09:49:34","modified_gmt":"2026-08-12T02:49:34","slug":"video-aspect-ratio","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/","title":{"rendered":"Video Aspect Ratio: Common Sizes, Formats, and How to Change It"},"content":{"rendered":"<span class=\"rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\">14<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span><p>One video aspect ratio ran the industry for more than half a century. The 4:3 frame held from the first moving-picture cameras until widescreen formats arrived in 1953 to answer television, and then 16:9 became the international HDTV standard, which settled the question for about two decades.<\/p>\n<p>Mobile unsettled it again. A single 1920\u00d71080 master now has to land on a 21:9 ultrawide monitor, a 16:9 living-room TV, and a 9:16 phone held upright. The width-to-height decisions in your pipeline decide whether it fills the screen or shows up boxed in black.<\/p>\n<p>Video aspect ratio is the proportion between a frame&#8217;s width and its height. That sounds like one number you set once.<\/p>\n<p>In a real pipeline it&#8217;s four numbers set in four places, and they can disagree with each other. That disagreement is what produces stretched faces, sideways phone clips, and layouts that jump when a player switches quality.<\/p>\n<h2>What Is Video Aspect Ratio?<\/h2>\n<p>Video aspect ratio is the proportional relationship between a video frame&#8217;s width and its height, written as width:height. A 16:9 frame is 16 units wide for every 9 units tall, which works out to 1.778:1.<\/p>\n<p>Two things follow from that definition.<\/p>\n<p>The ratio describes shape, not size. A 640\u00d7360 clip and a 3840\u00d72160 clip are both 16:9. They differ in resolution, pixel count, and file size, but they&#8217;re the same shape, so they fill the same screen without bars or distortion.<\/p>\n<p>The ratio is also a display property, not just a storage property. What you count in the file is a pixel grid, and what the viewer sees is that grid rendered on a display. Those two can differ if the pixels aren&#8217;t square.<\/p>\n<p>Most modern video uses square pixels, so the grid and the display shape match. Older and anamorphic formats break that assumption.<\/p>\n<p>Aspect ratio exists because capture and display hardware evolved separately. Cameras, film gauges, broadcast standards, monitors, and phones each settled on their own frame shape, so any real delivery chain has to reconcile at least two of them.<\/p>\n<table>\n<thead>\n<tr>\n<th>Ratio<\/th>\n<th>Decimal<\/th>\n<th>Orientation<\/th>\n<th>Where you see it<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>16:9<\/td>\n<td>1.778:1<\/td>\n<td>Landscape<\/td>\n<td>HDTV, YouTube, OTT, webinars<\/td>\n<\/tr>\n<tr>\n<td>9:16<\/td>\n<td>0.563:1<\/td>\n<td>Portrait<\/td>\n<td>TikTok, Reels, Shorts, Stories<\/td>\n<\/tr>\n<tr>\n<td>1:1<\/td>\n<td>1.0:1<\/td>\n<td>Square<\/td>\n<td>Social feeds<\/td>\n<\/tr>\n<tr>\n<td>4:3<\/td>\n<td>1.333:1<\/td>\n<td>Landscape<\/td>\n<td>Legacy broadcast, archives, some security cameras<\/td>\n<\/tr>\n<tr>\n<td>21:9<\/td>\n<td>2.37:1<\/td>\n<td>Ultrawide<\/td>\n<td>Cinema, ultrawide monitors<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Video Aspect Ratio vs Resolution vs Pixel Aspect Ratio<\/h2>\n<p>These three get used interchangeably, and mixing them up is the root cause of most stretched-video bugs. Here&#8217;s the split.<\/p>\n<p><strong>Resolution<\/strong> is the pixel count: 1920\u00d71080, 3840\u00d72160, 1080\u00d71920. It&#8217;s an absolute measurement of detail.<\/p>\n<p><strong>Aspect ratio<\/strong> is the shape those pixels form when displayed. Derived, relative, unitless.<\/p>\n<p><strong>Pixel aspect ratio (PAR)<\/strong> is the shape of one individual pixel. Square pixels are 1:1. Anything else means the stored grid and the displayed frame have different proportions.<\/p>\n<p>One formula connects all three. Storage aspect ratio times pixel aspect ratio equals display aspect ratio, or <a href=\"https:\/\/en.wikipedia.org\/wiki\/Aspect_ratio_%28image%29\" target=\"_blank\" rel=\"nofollow\">SAR \u00d7 PAR = DAR<\/a>.<\/p>\n<p>Storage aspect ratio is what you get by dividing the stored width by the stored height. Display aspect ratio is the shape the viewer actually sees. Run the numbers on two real formats:<\/p>\n<ul>\n<li><strong>PAL standard definition, 16:9.<\/strong> Stored at 720\u00d7576, so SAR is 1.25. PAR is 64:45, or 1.422. Multiply: 1.25 \u00d7 1.422 = 1.778, which is 16:9 on screen. The same 720\u00d7576 grid with a 16:15 PAR displays as 4:3 instead.<\/li>\n<li><strong>Anamorphic HDV.<\/strong> Stored at 1440\u00d71080, so SAR is 1.333. PAR is 4:3, or 1.333. Multiply: 1.333 \u00d7 1.333 = 1.778. Again 16:9, from a grid that counts as 4:3.<\/li>\n<\/ul>\n<p>One naming trap trips up nearly everyone reading FFmpeg output. In the H.264 specification and in FFmpeg logs, &#8220;SAR&#8221; means <em>sample<\/em> aspect ratio, which is the same thing as pixel aspect ratio. It isn&#8217;t storage aspect ratio.<\/p>\n<p>So a line like <code>1920x1080 [SAR 1:1 DAR 16:9]<\/code> is telling you the pixels are square and the display shape is 16:9.<\/p>\n<p>Check which values a file actually carries before you assume:<\/p>\n<pre><code class=\"language-bash\">ffprobe -v error -select_streams v:0 \\\n  -show_entries stream=width,height,sample_aspect_ratio,display_aspect_ratio \\\n  -of csv=p=0 input.mp4<\/code><\/pre>\n<p>If that returns <code>1920,1080,1:1,16:9<\/code>, the file agrees with itself. If it returns <code>1440,1080,4:3,16:9<\/code>, you&#8217;re holding anamorphic video and any tool that ignores PAR will render it squeezed.<\/p>\n<h2>Common Video Aspect Ratios and Their Resolutions<\/h2>\n<p>Aspect ratio choice is really a distribution decision, so it helps to know which shape belongs to which screen.<\/p>\n<h3>16:9 (Widescreen)<\/h3>\n<p>The default for landscape video and the international HDTV standard. Every common landscape resolution is 16:9: 1280\u00d7720, 1920\u00d71080, 2560\u00d71440, and 3840\u00d72160.<\/p>\n<p>Use it for anything watched on a TV, monitor, or laptop. That includes OTT catalogs, webinars, product demos, gaming streams, and long-form YouTube. If you only ship one landscape master, ship this one.<\/p>\n<h3>9:16 (Vertical)<\/h3>\n<p>16:9 rotated. The standard resolution is 1080\u00d71920, with 720\u00d71280 as the lighter option.<\/p>\n<p>It fills a phone screen held upright, which is why TikTok, Instagram Reels, YouTube Shorts, and Stories all default to it. If your audience discovers content on a phone, vertical is the native shape, and our guide to <a href=\"https:\/\/liveapi.com\/blog\/vertical-video-dimensions\/\" target=\"_blank\">vertical video dimensions<\/a> goes deeper on the numbers.<\/p>\n<h3>1:1 (Square)<\/h3>\n<p>1080\u00d71080. A square frame takes more vertical space in a feed than landscape without committing to a full-height portrait crop.<\/p>\n<p>It&#8217;s the safe middle when one asset has to work across several social feeds. It&#8217;s a compromise, though, so it wins nowhere outright.<\/p>\n<h3>4:5 (Portrait Feed)<\/h3>\n<p>1080\u00d71350. Taller than square, shorter than full vertical.<\/p>\n<p>Instagram and Facebook in-feed posts favor it because it claims screen height while still leaving room for the caption and interaction row.<\/p>\n<h3>4:3 (Fullscreen)<\/h3>\n<p>640\u00d7480, 1024\u00d7768, or 1440\u00d71080 anamorphic. This was the broadcast and early-computer standard before widescreen.<\/p>\n<p>You&#8217;ll still meet it in archive footage, older camera output, document cameras, and plenty of IP security cameras. If you ingest from cameras over RTSP, expect some 4:3 sources and plan how you&#8217;ll frame them.<\/p>\n<h3>21:9 (Ultrawide \/ Cinematic)<\/h3>\n<p>2560\u00d71080 and 3440\u00d71440. The marketing name says 21:9, but 2560\u00d71080 reduces to 64:27, which is 2.37:1.<\/p>\n<p>It matches ultrawide monitors and approximates theatrical widescreen. Outside cinema and PC gaming it&#8217;s rare, and it letterboxes heavily on a normal TV.<\/p>\n<h3>2.39:1 and 1.85:1 (Theatrical)<\/h3>\n<p>The two projection standards. 1.85:1 is the American flat standard, and 2.39:1 is anamorphic scope. In a DCI 4K container that&#8217;s 3996\u00d72160 for flat and 4096\u00d71716 for scope.<\/p>\n<p>Feature and premium episodic content is finished here, which is why so much streaming catalog content shows black bars on a 16:9 display.<\/p>\n<table>\n<thead>\n<tr>\n<th>Ratio<\/th>\n<th>Typical resolution<\/th>\n<th>Orientation<\/th>\n<th>Primary use<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>16:9<\/td>\n<td>1920\u00d71080 \/ 3840\u00d72160<\/td>\n<td>Landscape<\/td>\n<td>TV, OTT, YouTube, webinars<\/td>\n<\/tr>\n<tr>\n<td>9:16<\/td>\n<td>1080\u00d71920<\/td>\n<td>Portrait<\/td>\n<td>TikTok, Reels, Shorts<\/td>\n<\/tr>\n<tr>\n<td>1:1<\/td>\n<td>1080\u00d71080<\/td>\n<td>Square<\/td>\n<td>Multi-platform social<\/td>\n<\/tr>\n<tr>\n<td>4:5<\/td>\n<td>1080\u00d71350<\/td>\n<td>Portrait<\/td>\n<td>Instagram \/ Facebook feed<\/td>\n<\/tr>\n<tr>\n<td>4:3<\/td>\n<td>1024\u00d7768 \/ 1440\u00d71080<\/td>\n<td>Landscape<\/td>\n<td>Archives, IP cameras<\/td>\n<\/tr>\n<tr>\n<td>21:9<\/td>\n<td>2560\u00d71080 \/ 3440\u00d71440<\/td>\n<td>Ultrawide<\/td>\n<td>Ultrawide monitors, gaming<\/td>\n<\/tr>\n<tr>\n<td>2.39:1<\/td>\n<td>4096\u00d71716<\/td>\n<td>Ultrawide<\/td>\n<td>Theatrical, premium episodic<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>How to Calculate Video Aspect Ratio<\/h2>\n<p>To find the aspect ratio of a video, divide the pixel width by the pixel height, then reduce that fraction to its smallest whole numbers using the greatest common divisor.<\/p>\n<p>Three steps:<\/p>\n<ol>\n<li><strong>Divide width by height<\/strong> for the decimal ratio. 1920 \u00f7 1080 = 1.778.<\/li>\n<li><strong>Find the greatest common divisor<\/strong> of the two numbers. For 1920 and 1080, that&#8217;s 120.<\/li>\n<li><strong>Divide both sides by it.<\/strong> 1920 \u00f7 120 = 16 and 1080 \u00f7 120 = 9, so the ratio is 16:9.<\/li>\n<\/ol>\n<p>Run the same method on other resolutions:<\/p>\n<ul>\n<li>3840\u00d72160 \u2192 GCD 240 \u2192 <strong>16:9<\/strong><\/li>\n<li>1280\u00d7720 \u2192 GCD 80 \u2192 <strong>16:9<\/strong><\/li>\n<li>1080\u00d71920 \u2192 GCD 120 \u2192 <strong>9:16<\/strong><\/li>\n<li>1024\u00d7768 \u2192 GCD 256 \u2192 <strong>4:3<\/strong><\/li>\n<li>1080\u00d71350 \u2192 GCD 270 \u2192 <strong>4:5<\/strong><\/li>\n<li>2560\u00d71080 \u2192 GCD 40 \u2192 <strong>64:27<\/strong> (sold as 21:9)<\/li>\n<\/ul>\n<p>Two of those results are worth pausing on. 16:9 and 9:16 are the same ratio with the terms swapped, which is why a vertical clip is just a rotated widescreen frame.<\/p>\n<p>And 2560\u00d71080 shows that marketed ratios are sometimes rounded. Calculate rather than trust the label.<\/p>\n<p>Reverse the math to get dimensions from a target ratio. For 9:16 at 1080 wide, multiply 1080 by 16\/9 to get 1920 tall.<\/p>\n<p>One constraint to respect: keep both numbers even. H.264 and H.265 with 4:2:0 chroma subsampling store color at half resolution in each direction, so odd dimensions either fail to encode or get silently adjusted.<\/p>\n<p>H.264 also works in 16\u00d716 macroblocks, so dimensions that are multiples of 16 avoid the cropping flags encoders otherwise have to write into the bitstream.<\/p>\n<h2>Where Aspect Ratio Gets Set in a Video Pipeline<\/h2>\n<p>Aspect ratio isn&#8217;t one setting. It&#8217;s recorded or implied at four stages, and a mismatch at any one of them produces a visible bug.<\/p>\n<p><strong>1. Capture and ingest.<\/strong> The camera or encoder decides the source frame. A phone shoots 1080\u00d71920, a webcam 1280\u00d7720, an IP camera maybe 1024\u00d7768. If you accept <a href=\"https:\/\/liveapi.com\/blog\/what-is-rtmp\/\" target=\"_blank\">RTMP<\/a> or <a href=\"https:\/\/liveapi.com\/blog\/srt-protocol\/\" target=\"_blank\">SRT<\/a> from third parties, treat the incoming ratio as unknown until you probe it.<\/p>\n<p><strong>2. Transcode.<\/strong> This is where you can change shape by scaling, cropping, or padding. It&#8217;s also where <a href=\"https:\/\/liveapi.com\/blog\/what-is-video-transcoding\/\" target=\"_blank\">video transcoding<\/a> settings can accidentally change shape, usually by scaling width and height independently.<\/p>\n<p><strong>3. Bitstream and container metadata.<\/strong> The ratio gets written twice, in two places that can disagree. H.264 signals it in the SPS VUI through <code>aspect_ratio_idc<\/code> or explicit <code>sar_width<\/code>\/<code>sar_height<\/code>, while MP4 signals it in the <code>pasp<\/code> box in the video track. When those two conflict, different players resolve it differently, which is exactly why one file looks right in VLC and squeezed in a browser.<\/p>\n<p><strong>4. Packaging and playback.<\/strong> Your manifest carries resolution per rendition, and the player element carries a box that the frames get fitted into. Both stages can override what the viewer sees.<\/p>\n<p>The rotation matrix in the MP4 <code>tkhd<\/code> box deserves its own mention, because it causes the classic sideways-phone-video bug. A phone often records 1920\u00d71080 landscape pixels plus a 90-degree rotation flag, expecting the player to turn the frame.<\/p>\n<p>Players that honor the flag show correct vertical video. Tools that ignore it show a sideways 16:9 frame.<\/p>\n<p>Modern FFmpeg auto-rotates by default. But anything that reads raw dimensions from the container without checking that matrix will get the shape wrong.<\/p>\n<h2>Video Aspect Ratio by Platform<\/h2>\n<p>Every destination publishes its own preferred frame, and they don&#8217;t agree. Here&#8217;s what to target as of 2026.<\/p>\n<table>\n<thead>\n<tr>\n<th>Platform<\/th>\n<th>Best ratio<\/th>\n<th>Resolution<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>YouTube (standard)<\/td>\n<td>16:9<\/td>\n<td>1920\u00d71080<\/td>\n<td>Other ratios get pillarboxed automatically<\/td>\n<\/tr>\n<tr>\n<td>YouTube Shorts<\/td>\n<td>9:16<\/td>\n<td>1080\u00d71920<\/td>\n<td>Under 3 minutes<\/td>\n<\/tr>\n<tr>\n<td>TikTok<\/td>\n<td>9:16<\/td>\n<td>1080\u00d71920<\/td>\n<td>Keep text out of the top and bottom 15%<\/td>\n<\/tr>\n<tr>\n<td>Instagram Reels<\/td>\n<td>9:16<\/td>\n<td>1080\u00d71920<\/td>\n<td>UI overlays the lower third<\/td>\n<\/tr>\n<tr>\n<td>Instagram feed<\/td>\n<td>4:5 or 1:1<\/td>\n<td>1080\u00d71350 \/ 1080\u00d71080<\/td>\n<td>4:5 claims more feed height<\/td>\n<\/tr>\n<tr>\n<td>Facebook feed<\/td>\n<td>4:5 or 1:1<\/td>\n<td>1080\u00d71350<\/td>\n<td>9:16 for Reels<\/td>\n<\/tr>\n<tr>\n<td>LinkedIn<\/td>\n<td>16:9 or 1:1<\/td>\n<td>1920\u00d71080<\/td>\n<td>Square performs well in-feed<\/td>\n<\/tr>\n<tr>\n<td>X (Twitter)<\/td>\n<td>16:9 or 1:1<\/td>\n<td>1920\u00d71080<\/td>\n<td>16:9 for landscape posts<\/td>\n<\/tr>\n<tr>\n<td>Twitch<\/td>\n<td>16:9<\/td>\n<td>1920\u00d71080<\/td>\n<td>Vertical support is limited<\/td>\n<\/tr>\n<tr>\n<td>OTT \/ smart TV<\/td>\n<td>16:9<\/td>\n<td>1920\u00d71080 or 3840\u00d72160<\/td>\n<td>TV frames are landscape<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Two rules make this table easier to act on.<\/p>\n<p>Match the output ratio to the primary consumption device, not the capture device. Reframe a 16:9 webcam feed to 9:16 when your audience is phone-first, rather than shipping the ratio it happened to record in.<\/p>\n<p>And respect safe zones. Platform UI covers part of the frame, so keep captions, logos, and lower-third graphics inside the middle 70% vertically on 9:16 content. <a href=\"https:\/\/support.google.com\/youtube\/answer\/1722171\" target=\"_blank\" rel=\"nofollow\">YouTube&#8217;s upload encoding recommendations<\/a> spell out the same idea for landscape.<\/p>\n<p>When one production has to reach several of these destinations, pick one ingest ratio and let your distribution layer fan it out. That&#8217;s the practical shape of <a href=\"https:\/\/liveapi.com\/blog\/stream-to-multiple-platforms\/\" target=\"_blank\">streaming to multiple platforms<\/a> at once.<\/p>\n<h2>What Goes Wrong When Aspect Ratios Don&#8217;t Match<\/h2>\n<p>No pipeline avoids mismatches entirely, because sources and destinations genuinely differ. What matters is which failure mode you choose.<\/p>\n<h3>Letterboxing and pillarboxing<\/h3>\n<p>Put a wide frame in a tall window and you get horizontal black bars above and below, which is letterboxing. Put a tall frame in a wide window and you get vertical bars on the sides, which is pillarboxing.<\/p>\n<p>Both preserve the whole image and the correct geometry. They cost screen area, and on a phone a pillarboxed 16:9 clip can end up using less than a third of the display.<\/p>\n<p>The fix: reframe for the destination instead of relying on the player to pad.<\/p>\n<h3>Stretching and squeezing<\/h3>\n<p>Scale width and height by different factors and every object in the frame distorts. Faces widen, circles turn into ovals.<\/p>\n<p>Viewers notice this one immediately. It almost always comes from forcing an output resolution without accounting for the source ratio.<\/p>\n<p>The fix: scale proportionally, then pad or crop for the difference.<\/p>\n<h3>Lost content from cropping<\/h3>\n<p>Cropping fills the frame, but everything outside the crop window is gone. Center-cropping a 16:9 interview to 9:16 discards roughly two thirds of the width, which routinely cuts off a second speaker or burned-in captions.<\/p>\n<p>The fix: reframe around the subject, or shoot wider than your delivery ratio so there&#8217;s margin to work with.<\/p>\n<h3>Metadata disagreement<\/h3>\n<p>The bitstream says one PAR, the container says another, and each player picks a winner. The file then renders correctly in one app and squeezed in the next, with no visible cause in the pixels themselves.<\/p>\n<p>The fix: normalize the metadata on ingest so both layers state the same thing.<\/p>\n<h3>Encoding artifacts from odd dimensions<\/h3>\n<p>Non-even dimensions collide with 4:2:0 chroma subsampling, and dimensions far off a multiple of 16 add cropping flags that some decoders handle poorly. Symptoms range from a one-pixel green edge to an outright encoder error.<\/p>\n<p>The fix: round every output dimension to an even number, and to a multiple of 16 where you can.<\/p>\n<h3>Wasted bitrate on padded pixels<\/h3>\n<p>Bake black bars into the frame and you&#8217;re encoding those bars. They compress well, so the cost is small, but it isn&#8217;t zero, and it&#8217;s permanent. A padded 9:16 upload of a 16:9 source spends part of its <a href=\"https:\/\/liveapi.com\/blog\/bitrate-for-1080p\/\" target=\"_blank\">bitrate<\/a> budget on black.<\/p>\n<p>The fix: pad at playback with the player box rather than in the encoded frame, whenever the destination allows it.<\/p>\n<p>Now that you know how the ratio behaves and where it breaks, here&#8217;s how to control it: the commands that change it, the pipeline settings that hold it, and the checklist for picking one.<\/p>\n<h2>How to Change a Video&#8217;s Aspect Ratio<\/h2>\n<p>Three operations change the shape of a frame: crop, pad, or rewrite the metadata. Which one you pick depends on whether you&#8217;re willing to lose content, lose screen area, or neither.<\/p>\n<h3>Option 1: Crop to fill the frame<\/h3>\n<p>Cropping cuts pixels away so the remaining frame matches the target ratio. It fills the screen and loses whatever fell outside the window.<\/p>\n<p>Convert 1920\u00d71080 to 9:16:<\/p>\n<pre><code class=\"language-bash\">ffmpeg -i input.mp4 \\\n  -vf \"crop='trunc(ih*9\/16\/2)*2':ih,scale=1080:1920\" \\\n  -c:a copy output.mp4<\/code><\/pre>\n<p>The <code>trunc(...)*2<\/code> wrapper is doing real work. A 9:16 crop of a 1080-pixel-tall frame wants 607.5 pixels of width, and that isn&#8217;t a legal dimension, so the expression rounds down to the nearest even number. The <code>scale<\/code> step then resizes to exactly 1080\u00d71920.<\/p>\n<p>By default <code>crop<\/code> centers the window. Shift it with explicit x and y values when your subject isn&#8217;t centered:<\/p>\n<pre><code class=\"language-bash\">ffmpeg -i input.mp4 -vf \"crop=606:1080:400:0,scale=1080:1920\" -c:a copy output.mp4<\/code><\/pre>\n<h3>Option 2: Pad to letterbox or pillarbox<\/h3>\n<p>Padding keeps the entire image and fills the leftover space with bars. Nothing is lost and nothing is distorted.<\/p>\n<p>Fit a 1080\u00d71920 vertical source into a 16:9 frame:<\/p>\n<pre><code class=\"language-bash\">ffmpeg -i input.mp4 \\\n  -vf \"scale=1920:1080:force_original_aspect_ratio=decrease:force_divisible_by=2,\\\npad=1920:1080:(ow-iw)\/2:(oh-ih)\/2:black\" \\\n  -c:a copy output.mp4<\/code><\/pre>\n<p>Two flags carry this command. <code>force_original_aspect_ratio=decrease<\/code> scales the source to fit inside the target box without distortion, and <code>force_divisible_by=2<\/code> keeps the result even. The <code>pad<\/code> filter then centers that scaled frame in a 1920\u00d71080 canvas.<\/p>\n<p>Swap <code>black<\/code> for any color if bars are part of your brand treatment.<\/p>\n<h3>Option 3: Rewrite the metadata only<\/h3>\n<p>Sometimes the pixels are fine and only the signaled ratio is wrong. The <code>setsar<\/code> and <code>setdar<\/code> filters change what the file claims without resampling anything, and the <a href=\"https:\/\/ffmpeg.org\/ffmpeg-filters.html\" target=\"_blank\" rel=\"nofollow\">FFmpeg filter documentation<\/a> spells out how they interact.<\/p>\n<pre><code class=\"language-bash\">ffmpeg -i input.mp4 -vf \"setsar=1\/1,setdar=16\/9\" -c:v libx264 -crf 20 -c:a copy output.mp4<\/code><\/pre>\n<p>Use this to fix anamorphic source that players are rendering squeezed, or to strip an incorrect PAR from a legacy file. It won&#8217;t fix a genuinely mis-shaped frame, because no pixels move.<\/p>\n<h3>Option 4: Scale within the same ratio<\/h3>\n<p>If the shape is already right and you only need different dimensions, scale one axis and let FFmpeg derive the other:<\/p>\n<pre><code class=\"language-bash\">ffmpeg -i input.mp4 -vf \"scale=1280:-2\" -c:a copy output.mp4<\/code><\/pre>\n<p>The <code>-2<\/code> tells FFmpeg to compute the height from the source ratio and round to an even number. This is the safest resize you can run, because it can&#8217;t distort geometry.<\/p>\n<h3>Do it with an API instead of a render farm<\/h3>\n<p>Running these commands once is easy. Running them for every upload, at every rung of a ladder, is a service you now have to operate, along with the queue, the retries, and the storage around it.<\/p>\n<p>That&#8217;s the point where a video API earns its keep. <a href=\"https:\/\/liveapi.com\/\" target=\"_blank\">LiveAPI<\/a> accepts RTMP, SRT, RTSP, and direct file uploads up to 4K, then encodes into an adaptive bitrate ladder and HLS output. Instant encoding means videos are playable seconds after upload no matter how long they run.<\/p>\n<p>You set the frame shape at your encoder or in your source file, and the platform carries it through transcoding, packaging, and its embeddable HTML5 player. No transcode workers to maintain. The <a href=\"https:\/\/liveapi.com\/blog\/video-upload-api\/\" target=\"_blank\">video upload API<\/a> covers files of any size or format, including URL imports.<\/p>\n<h3>Verify before you ship<\/h3>\n<p>Always probe the output rather than trusting the command:<\/p>\n<pre><code class=\"language-bash\">ffprobe -v error -select_streams v:0 \\\n  -show_entries stream=width,height,sample_aspect_ratio,display_aspect_ratio,r_frame_rate \\\n  -of default=noprint_wrappers=1 output.mp4<\/code><\/pre>\n<p>Check three things in the output:<\/p>\n<ul>\n<li>Both dimensions are even numbers<\/li>\n<li>The sample aspect ratio is 1:1 for square-pixel delivery<\/li>\n<li>The display aspect ratio is the shape you intended<\/li>\n<\/ul>\n<h2>How to Handle Video Aspect Ratio in a Streaming Pipeline<\/h2>\n<p>For live and on-demand streaming, the ratio has to survive four more stages after the file is correct. Each one needs a decision.<\/p>\n<h3>Keep the ladder in one ratio<\/h3>\n<p>Every rung of your <a href=\"https:\/\/liveapi.com\/blog\/adaptive-bitrate-streaming\/\" target=\"_blank\">adaptive bitrate<\/a> ladder must share the same aspect ratio. If one rung is 16:9 and another is 4:3, players resize the video element mid-stream on a quality switch and viewers see the frame jump.<\/p>\n<p>A clean 16:9 ladder looks like 3840\u00d72160, 1920\u00d71080, 1280\u00d7720, 854\u00d7480, and 640\u00d7360. Note the 854 rather than 853.33, rounded up to stay even. For 9:16, run 1080\u00d71920, 720\u00d71280, 540\u00d7960, and 360\u00d7640.<\/p>\n<p>Hold <a href=\"https:\/\/liveapi.com\/blog\/video-frame-rate\/\" target=\"_blank\">frame rate<\/a> and <a href=\"https:\/\/liveapi.com\/blog\/keyframe-interval\/\" target=\"_blank\">keyframe interval<\/a> constant across rungs too, so switches stay invisible.<\/p>\n<h3>Signal the ratio in the manifest<\/h3>\n<p><a href=\"https:\/\/liveapi.com\/blog\/what-is-hls\/\" target=\"_blank\">HLS<\/a> declares dimensions per variant in the <code>RESOLUTION<\/code> attribute of each <code>#EXT-X-STREAM-INF<\/code> tag:<\/p>\n<pre><code>#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS=\"avc1.640028,mp4a.40.2\"\n1080p\/index.m3u8<\/code><\/pre>\n<p><a href=\"https:\/\/liveapi.com\/blog\/mpeg-dash\/\" target=\"_blank\">MPEG-DASH<\/a> is more explicit. <code>Representation<\/code> elements carry <code>@width<\/code>, <code>@height<\/code>, and <code>@sar<\/code>, and the parent <code>AdaptationSet<\/code> carries <code>@par<\/code> for the picture aspect ratio, so a compliant player can size its viewport before it fetches a single segment.<\/p>\n<p>Both formats assume your <a href=\"https:\/\/liveapi.com\/blog\/fragmented-mp4\/\" target=\"_blank\">fragmented MP4<\/a> segments agree with what the manifest claims. When they don&#8217;t, players trust the bitstream and your layout breaks.<\/p>\n<h3>Size the player container correctly<\/h3>\n<p>Client-side, the aspect ratio is a CSS problem. Reserve the space with <code>aspect-ratio<\/code> so the page doesn&#8217;t shift while the stream loads, then decide how frames fit the box:<\/p>\n<pre><code class=\"language-css\">.player-wrapper {\n  width: 100%;\n  aspect-ratio: 16 \/ 9;\n  background: #000;\n}\n\n.player-wrapper video {\n  width: 100%;\n  height: 100%;\n  object-fit: contain; \/* letterbox: shows the whole frame *\/\n}<\/code><\/pre>\n<p><code>object-fit: contain<\/code> preserves the full frame and adds bars where the shapes differ. <code>object-fit: cover<\/code> fills the container and crops the overflow. <code>fill<\/code> stretches, so avoid it in delivery code.<\/p>\n<p>If you&#8217;re wiring this up with <a href=\"https:\/\/liveapi.com\/blog\/hls-js\/\" target=\"_blank\">hls.js<\/a> or a framework component, read dimensions from the loaded level rather than hardcoding them, and our <a href=\"https:\/\/liveapi.com\/blog\/react-video-player\/\" target=\"_blank\">React video player<\/a> guide shows that pattern. A <a href=\"https:\/\/liveapi.com\/blog\/video-player-api\/\" target=\"_blank\">video player API<\/a> that handles responsive sizing removes the problem from your codebase entirely.<\/p>\n<h3>Normalize on ingest<\/h3>\n<p>Probe every incoming stream and normalize it to one house ratio before you transcode. It&#8217;s the single most useful habit in a multi-source pipeline.<\/p>\n<p>Four steps do it:<\/p>\n<ul>\n<li>Set an explicit PAR<\/li>\n<li>Strip or apply the rotation flag<\/li>\n<li>Round both dimensions to even numbers<\/li>\n<li>Record the source ratio so you can reframe later<\/li>\n<\/ul>\n<p>That single step prevents most downstream surprises, whether frames arrive from a phone, a browser capture, or a hardware <a href=\"https:\/\/liveapi.com\/blog\/live-streaming-encoder\/\" target=\"_blank\">live streaming encoder<\/a>. It also makes embedding predictable when you <a href=\"https:\/\/liveapi.com\/blog\/embed-live-stream-on-website\/\" target=\"_blank\">embed a live stream on a website<\/a> with a fixed layout.<\/p>\n<h2>Choosing the Right Aspect Ratio for Your Project<\/h2>\n<p>Pick the ratio from where your video gets watched, then work backwards to capture.<\/p>\n<p><strong>Go with 16:9 if:<\/strong><\/p>\n<ul>\n<li>Viewers watch on TVs, laptops, or desktop monitors<\/li>\n<li>You&#8217;re shipping OTT, webinars, courses, or long-form video<\/li>\n<li>Your content has wide framing, multiple speakers, or shared screens<\/li>\n<li>You want one master that works across the most destinations<\/li>\n<li>Your archive is already landscape<\/li>\n<\/ul>\n<p><strong>Go with 9:16 if:<\/strong><\/p>\n<ul>\n<li>Discovery happens on TikTok, Reels, or Shorts<\/li>\n<li>Your audience watches almost entirely on phones<\/li>\n<li>The subject is a single person, product, or close-up<\/li>\n<li>You&#8217;re building a mobile-first app where video is full-screen<\/li>\n<\/ul>\n<p><strong>Go with 1:1 or 4:5 if:<\/strong><\/p>\n<ul>\n<li>The asset has to work across several social feeds without recuts<\/li>\n<li>In-feed impressions matter more than immersive playback<\/li>\n<\/ul>\n<p><strong>Reconsider a single ratio if:<\/strong><\/p>\n<ul>\n<li>You publish to both TV-class and phone-first destinations<\/li>\n<li>Your source is 4:3 or theatrical and neither crop nor pad is acceptable<\/li>\n<li>Reframing would cut off captions, graphics, or a second subject<\/li>\n<\/ul>\n<p>In that last case, produce two outputs rather than compromising on one. Capture wider than your delivery ratio, cut a landscape master and a vertical version, and run both through the same encoding workflow so quality stays consistent.<\/p>\n<h2>Video Aspect Ratio FAQ<\/h2>\n<h3>What is the standard video aspect ratio?<\/h3>\n<p>16:9 is the standard for landscape video and the international HDTV format. It covers 1280\u00d7720, 1920\u00d71080, 2560\u00d71440, and 3840\u00d72160. For mobile-first content, 9:16 at 1080\u00d71920 is the de facto standard.<\/p>\n<h3>What is 16:9 in pixels?<\/h3>\n<p>16:9 isn&#8217;t a fixed pixel count, since it&#8217;s a shape. Common 16:9 resolutions are 640\u00d7360, 1280\u00d7720, 1920\u00d71080, 2560\u00d71440, and 3840\u00d72160. Any width and height that divide down to 16:9 qualifies.<\/p>\n<h3>What&#8217;s the difference between aspect ratio and resolution?<\/h3>\n<p>Resolution is the absolute pixel count, like 1920\u00d71080. Aspect ratio is the proportion those pixels form, like 16:9. Different resolutions can share one ratio, which is exactly how an adaptive bitrate ladder switches quality without changing frame shape.<\/p>\n<h3>Why does YouTube add black bars to my video?<\/h3>\n<p>YouTube&#8217;s player is 16:9, so anything narrower gets pillarboxed with vertical bars and anything wider gets letterboxed with horizontal bars. Upload at 16:9 for standard videos, or 9:16 for Shorts, and the bars disappear.<\/p>\n<h3>How do I change the aspect ratio of a video without cropping?<\/h3>\n<p>Pad instead of crop. Scale the source proportionally to fit inside the target frame, then fill the remaining space with bars using FFmpeg&#8217;s <code>scale<\/code> with <code>force_original_aspect_ratio=decrease<\/code> followed by <code>pad<\/code>. Nothing gets cut and nothing gets distorted, but you lose some screen area.<\/p>\n<h3>Does aspect ratio affect video quality or file size?<\/h3>\n<p>Not directly, since ratio describes shape and resolution drives pixel count. It affects file size indirectly in two ways: taller frames at the same width carry more pixels, and baked-in black bars consume a small share of your bitrate.<\/p>\n<h3>What is the best aspect ratio for live streaming?<\/h3>\n<p>16:9 for desktop and TV destinations like Twitch, LinkedIn Live, and standard YouTube, and 9:16 for phone-first destinations. Decide before you go live, because reframing a live stream mid-broadcast means either cropping or padding in real time.<\/p>\n<h3>What is pixel aspect ratio and do I still need to care?<\/h3>\n<p>Pixel aspect ratio is the shape of an individual pixel. Modern video uses square 1:1 pixels, so you can usually ignore it. It still matters with standard-definition, anamorphic, and older camera formats, where a non-square PAR is what makes a 1440\u00d71080 grid display as 16:9.<\/p>\n<h3>Is 4:3 still used anywhere?<\/h3>\n<p>Yes, in narrower places. Archive footage, older camera output, document cameras, and many IP security cameras still produce 4:3. If you ingest from third-party sources, handle it rather than assuming everything arrives widescreen.<\/p>\n<h3>Can I deliver more than one aspect ratio from one stream?<\/h3>\n<p>Not from a single encoded rendition, since each rendition has one frame shape. You&#8217;d produce separate outputs from the same source, either by encoding two ladders or by reframing server-side. Keep each ladder internally consistent so quality switches stay smooth.<\/p>\n<h2>Getting the Frame Right<\/h2>\n<p>Video aspect ratio looks like a creative choice and behaves like a pipeline property. The shape gets asserted at capture, changed at transcode, recorded in both the bitstream and the container, declared in the manifest, and finally interpreted by a player box.<\/p>\n<p>Any of those five can contradict the other four.<\/p>\n<p>Five habits prevent nearly every aspect ratio bug:<\/p>\n<ul>\n<li>Probe your source instead of assuming its shape<\/li>\n<li>Normalize everything to one house ratio on ingest<\/li>\n<li>Keep every dimension even<\/li>\n<li>Hold the ratio constant across your ABR ladder<\/li>\n<li>Let the player pad, rather than baking bars into pixels<\/li>\n<\/ul>\n<p><strong>Ready to ship video that holds its shape end to end?<\/strong> LiveAPI handles RTMP, SRT, and RTSP ingest up to 4K, instant encoding into an HLS adaptive bitrate ladder, and an embeddable player that plays back correctly across screen sizes. <a href=\"https:\/\/liveapi.com\/features\/\" target=\"_blank\">Try LiveAPI free<\/a> and go live in days instead of months.<\/p>\n","protected":false},"excerpt":{"rendered":"<p><span class=\"rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\">14<\/span> <span class=\"rt-label rt-postfix\">minutes<\/span><\/span> One video aspect ratio ran the industry for more than half a century. The 4:3 frame held from the first moving-picture cameras until widescreen formats arrived in 1953 to answer television, and then 16:9 became the international HDTV standard, which settled the question for about two decades. Mobile unsettled it again. A single 1920\u00d71080 master [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":1256,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_title":"Video Aspect Ratio: Sizes, Formats, and How to Change It %%sep%% %%sitename%%","_yoast_wpseo_metadesc":"Learn what video aspect ratio means, common ratios like 16:9 and 9:16, how to calculate it, platform requirements, and how to change it with FFmpeg.","inline_featured_image":false,"footnotes":""},"categories":[16],"tags":[],"class_list":["post-1255","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-video-format"],"jetpack_featured_media_url":"https:\/\/liveapi.com\/blog\/wp-content\/uploads\/2026\/08\/video-aspect-ratio.jpg","yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v15.6.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<meta name=\"description\" content=\"Learn what video aspect ratio means, common ratios like 16:9 and 9:16, how to calculate it, platform requirements, and how to change it with FFmpeg.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Video Aspect Ratio: Sizes, Formats, and How to Change It - LiveAPI Blog\" \/>\n<meta property=\"og:description\" content=\"Learn what video aspect ratio means, common ratios like 16:9 and 9:16, how to calculate it, platform requirements, and how to change it with FFmpeg.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/\" \/>\n<meta property=\"og:site_name\" content=\"LiveAPI Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-08-12T02:49:01+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-08-12T02:49:34+00:00\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\">\n\t<meta name=\"twitter:data1\" content=\"20 minutes\">\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebSite\",\"@id\":\"https:\/\/liveapi.com\/blog\/#website\",\"url\":\"https:\/\/liveapi.com\/blog\/\",\"name\":\"LiveAPI Blog\",\"description\":\"Live Video Streaming API Blog\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/liveapi.com\/blog\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/#primaryimage\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/liveapi.com\/blog\/wp-content\/uploads\/2026\/08\/video-aspect-ratio.jpg\",\"width\":1880,\"height\":1253,\"caption\":\"Photo by Wallace Chuck on Pexels\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/#webpage\",\"url\":\"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/\",\"name\":\"Video Aspect Ratio: Sizes, Formats, and How to Change It - LiveAPI Blog\",\"isPartOf\":{\"@id\":\"https:\/\/liveapi.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/#primaryimage\"},\"datePublished\":\"2026-08-12T02:49:01+00:00\",\"dateModified\":\"2026-08-12T02:49:34+00:00\",\"author\":{\"@id\":\"https:\/\/liveapi.com\/blog\/#\/schema\/person\/98f2ee8b3a0bd93351c0d9e8ce490e4a\"},\"description\":\"Learn what video aspect ratio means, common ratios like 16:9 and 9:16, how to calculate it, platform requirements, and how to change it with FFmpeg.\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/liveapi.com\/blog\/video-aspect-ratio\/\"]}]},{\"@type\":\"Person\",\"@id\":\"https:\/\/liveapi.com\/blog\/#\/schema\/person\/98f2ee8b3a0bd93351c0d9e8ce490e4a\",\"name\":\"govz\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/liveapi.com\/blog\/#personlogo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/ab5cbe0543c0a44dc944c720159323bd001fc39a8ba5b1f137cd22e7578e84c9?s=96&d=mm&r=g\",\"caption\":\"govz\"},\"sameAs\":[\"https:\/\/liveapi.com\/blog\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","_links":{"self":[{"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/posts\/1255","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/comments?post=1255"}],"version-history":[{"count":1,"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/posts\/1255\/revisions"}],"predecessor-version":[{"id":1257,"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/posts\/1255\/revisions\/1257"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/media\/1256"}],"wp:attachment":[{"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/media?parent=1255"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/categories?post=1255"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/liveapi.com\/blog\/wp-json\/wp\/v2\/tags?post=1255"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}