Pixel Aspect Ratio vs Display Aspect Ratio Explained
- What is pixel aspect ratio versus display aspect ratio?
- Which ratio describes which part of the image?
- How do you calculate the displayed shape?
- What happens if you force square pixels without resizing?
- Why are interpretation, scaling, and cropping different?
- What should you inspect before choosing an output?
- How do you verify a separate delivery copy?
- Frequently asked questions
- Sources
What is pixel aspect ratio versus display aspect ratio?
Pixel aspect ratio describes the shape used to display one pixel; display aspect ratio describes the width-to-height shape of the whole picture. For a full, unrotated raster, display aspect ratio equals stored width divided by stored height, multiplied by pixel aspect ratio. Do not infer the intended shape from dimensions alone. Work only with authorized media, preserve originals, and check the source interpretation and destination documentation before changing settings or accepting an output.
This is a desk-researched interpretation guide with original arithmetic examples. It is not a report of encoding tests, and the sample numbers are not repair settings for an unidentified file.
If a converted image looks too wide or too narrow, begin by separating three questions: how many samples are stored, what shape each represents, and what shape the picture is meant to have.
Which ratio describes which part of the image?
Adobe's current Premiere documentation distinguishes the frame's aspect ratio from the aspect ratio of its pixels. It also explains that a misinterpreted pixel ratio can cause an incorrect frame shape.
| Property | What it describes | Illustrative notation |
|---|---|---|
| Stored dimensions | Columns and rows in the raster | 720 × 576 |
| Pixel aspect ratio, PAR | Display width relative to height of one pixel | 64:45 |
| Display aspect ratio, DAR | Displayed picture width relative to height | 16:9 |
FFmpeg uses sample aspect ratio, abbreviated SAR, for the pixel-ratio concept. In this article, SAR means that, not a separate abbreviation for storage aspect ratio. Read the tool's definition rather than assuming every source uses the same acronym.
Square pixels have a ratio of 1:1. With square pixels, dividing stored width by stored height gives the full raster's display ratio directly. With non-square pixels, it does not.
Our format basics collection covers the surrounding container and codec vocabulary. File extension, compression format, and picture geometry answer different questions.
How do you calculate the displayed shape?
The FFmpeg setdar and setsar documentation gives this relationship:
DAR = stored width ÷ stored height × SAR
Use the exact fraction where available. A colon in 16:9 means the same ratio as the fraction 16/9; it is not a pixel count.
The examples below assume an unrotated picture using the complete stored raster. They deliberately exclude crop regions, clean-aperture interpretation, and other transformations. They are mathematical illustrations, not a rule assigning one pixel ratio to every historical video standard.
For a square-pixel example:
1920 ÷ 1080 × 1 = 16/9
For a second raster, begin with its stored ratio:
720 ÷ 576 = 5/4
Now compare three possible pixel-ratio interpretations:
| Stored raster | Pixel ratio | Calculation | Resulting DAR |
|---|---|---|---|
| 720 × 576 | 1:1 | 5/4 × 1 | 5:4 |
| 720 × 576 | 16:15 | 5/4 × 16/15 = 80/60 | 4:3 |
| 720 × 576 | 64:45 | 5/4 × 64/45 = 320/180 | 16:9 |
The stored dimensions did not change between rows. The display interpretation did. That is why “the file is 720 × 576” is an incomplete answer to “what shape should it be?”
Do not infer a camera, broadcast standard, disc specification, or intended composition from this table. Use the source's actual documentation and metadata. A real format may define an active picture differently from this deliberately simple full-raster model.
What happens if you force square pixels without resizing?
Consider only the fictional 720 × 576, 64:45 example above. Its intended full-raster display ratio is 16:9. If you keep the stored dimensions but replace the pixel ratio with 1:1, the formula gives 5:4 instead.
That change does not preserve the original geometry.
To express the same 16:9 rectangle with square pixels while retaining a height of 576, the mathematical width is:
576 × 16/9 = 1024
So 1024 × 576 with 1:1 pixels and 720 × 576 with 64:45 pixels describe the same full-raster display shape in this example. They do not describe identical stored images or promise identical quality.
The wider stored raster would require a resizing decision, not merely a new interpretation of the existing sample count. The example establishes geometry only; it does not choose a resampling filter, codec, bitrate, or delivery format.
Why are interpretation, scaling, and cropping different?
Keep these decisions separate:
- Interpretation: what shape the existing samples represent.
- Scaling: what stored dimensions the output will use.
- Cropping: which part of the picture remains.
- Placement: how that picture fits within the destination frame.
FFmpeg states that setdar changes the sample aspect ratio without changing the frame's pixel dimensions. Later filters can change the resulting ratio again. This does not make every workflow using a ratio control a lossless metadata edit: the complete export process still matters.
Our guide to conversion without quality loss explains the broader distinction between copying compatible streams and generating a new encode.
Cropping deserves its own review. HandBrake's current resizing guide describes automatic black-bar detection as an estimate that can be wrong and provides a preview route. Do not accept a crop merely because it was chosen automatically. Examine relevant edges, text, and changes of framing across the recording.
No combination of pleasing proportions and fewer bars establishes that every required part of the image survived.
What should you inspect before choosing an output?
Make an original geometry record for each source rather than applying one remembered setting to a batch:
| Record field | What to capture |
|---|---|
| Source identity | A filename or internal identifier, not a public upload |
| Tool context | Inspector or editor name and installed version |
| Stored dimensions | Reported width and height |
| Pixel ratio | Exact reported fraction, or explicitly unknown |
| Intended display shape | Supporting source or delivery documentation |
| Other interpretation | Rotation, crop, or active-image information needing review |
| Destination | Required frame shape, pixel convention, and receiving application |
A media inspector can help collect information. The ffprobe documentation describes reporting container and stream information in readable or machine-readable forms. An inspector report is evidence about the file, not independent proof that every recorded value is correct.
If the pixel ratio is missing or conflicting, write “unknown” in your working record. Do not silently replace it with square pixels. Seek the export specification, capture documentation, or help from the source creator or a qualified post-production specialist.
Use trusted, current tools with media you are authorized to process. Do not upload private footage merely to get a convenient property readout.
How do you verify a separate delivery copy?
Our suggested review order is source interpretation first, destination requirements second, and output inspection third. Keep the original and backup unchanged.
Record one proposed change and its reason. For example, “destination requires square pixels; preserve documented display shape” is useful. “Make it look normal” does not identify what changed or why.
Compare the output at the intended viewing size and in the receiving workflow. Check the image boundaries as well as proportions. Review captions, graphics, and any shots whose composition makes a crop important. Also retain the usual duration, audio, synchronization, and stream checks; geometry is only one part of acceptance.
A preview that fits your editor's window is not proof that the exported file meets the destination's requirements. Follow the documentation for the installed application and inspect the actual separate output before approving it. The compression workflows collection keeps this verification distinct from choosing a smaller file.
There is no need to delete a source as part of understanding its aspect ratio. Keep any later retention decision separate from this inspection task.
Frequently asked questions
Does 720 × 576 always mean 4:3 video?
No. Those numbers describe the stored raster. In this guide's full-raster examples, 720 × 576 with pixel ratio 16:15 displays at 4:3, while pixel ratio 64:45 gives 16:9. Real format and active-image conventions still matter. Identify the actual source instead of assigning a ratio from the dimensions alone.
Does changing display aspect ratio add pixels?
Not necessarily. FFmpeg documents that its setdar filter changes sample aspect ratio rather than the frame's pixel dimensions. That statement concerns the filter, not the entire export path or every application. Scaling to a different stored width or height is a different operation. Preserve the source and verify what the selected workflow actually writes.
Should every video use square pixels?
No universal setting fits every source and destination. Square pixels simplify the relationship between stored dimensions and display shape, but a valid non-square-pixel source should not be relabeled blindly. Obtain the receiving specification, establish the source's intended geometry, and decide whether the delivery requires an actual square-pixel resample.
Can black bars prove that an aspect ratio is wrong?
No. Bars may be part of the stored image or added while fitting a correctly shaped picture into a differently shaped viewing area. Inspect the source and playback settings before cropping. Preserve captions and relevant image edges; removing visible bars without understanding their origin can change the composition or discard content.
What if two players show the same file differently?
Record both applications and their display settings, then compare the source's dimensions, pixel ratio, and relevant display interpretation. Different appearance is a reason to investigate, not proof that one player is automatically correct. Use the documented source and delivery requirements; keep the original and verify any separate output in the actual receiving workflow.
Sources
Primary documentation opened and read September 8, 2026: