Pixel aspect ratio calculator
A 720×480 frame meant to look 4:3 has pixels shaped 8:9, not square ones. Enter the display ratio and the stored resolution to get the shape of one pixel, so circles stay round in DV, DVD and standard-definition video. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Width
- 1,920
- Height
- 1,080
- Dar width
- 16
- Dar height
- 9
- Pixel aspect ratio
- 1
- Par width
- 1
- Par height
- 1
- Par
- 1:1
Pixel aspect ratio, often abbreviated PAR, is the shape of a single sample in a stored video frame: how wide that pixel is compared with its height when the picture is shown on a square-pixel display. Modern HD and UHD footage almost always uses square pixels, so PAR is 1:1 and the stored grid already matches the picture you see. Analogue-era DV tapes, DVD titles, and standard-definition broadcast masters still store 720×480 or 720×576 rasters that must be stretched to a 4:3 or 16:9 picture, which means each stored sample is slightly fat or slightly thin. This calculator accepts the display aspect ratio as two positive parts and the coded pixel width and height, then returns PAR = (display aspect × height) / width, the reduced PAR fraction, the matching storage and display ratios, and a square-pixel flag.
What pixel aspect ratio is, and how it differs from display aspect ratio
Three related ratios describe a video frame, and mixing them is the usual source of squeezed or stretched pictures. Display aspect ratio is that intended on-screen picture, the 4:3 or 16:9 (or 2.39:1) the director framed. Pixel aspect ratio is the missing link: the shape of one sample, equal to display aspect divided by storage aspect.
MPEG-4 writes the same identity as PAR = (DAR × height) / width. When PAR is 1:1 the pixels are square and a generic width-to-height calculator already tells you the picture; when PAR is 8:9 or 16:15 the decoder must scale the raster before the image looks correct. That is why a 720×480 NTSC DV clip tagged 4:3 does not have square pixels, and why dropping it onto a 1:1 timeline without a sample-aspect flag makes circles look like ovals.
You already know the intended display ratio and the stored resolution; you need the sample shape those two facts imply, as a decimal and as a reduced fraction you can paste into a muxer, a NLE, or a transcode filter.
Who needs the pixel aspect ratio, and when
Video engineers use a PAR calculator when a probe shows 720×480 or 720×576 and a container flag says 4:3 or 16:9, and they need the sample-aspect value to write into FFmpeg, MP4, MKV, or an NLE interpret dialog so circles stay round after conform. Archivists restoring DV, DigiBeta, and DVD titles need a deterministic oracle that does not silently assume square pixels the way a still-image pipeline would.
Educators explaining why 720×480 is not 4:3 in the grid can show the three ratios side by side without a blackboard full of cancelled fractions. The calculator does not open a media file, does not read a container SAR box, and does not guess DAR from a filename. You supply the four dimensions; it returns the ratio.
Keep requests small, pin the reduced par string in tests, and you get a reproducible pixel aspect ratio for muxers, lesson keys, and edge workers without standing up a media framework of your own.
What you can do with it
Tag SD rasters before a square-pixel timeline
Given 720×480 or 720×576 plus a 4:3 or 16:9 display flag, obtain the reduced PAR (8:9, 16:15, 32:27, 64:45) to write into a muxer or NLE so the picture is not squeezed.
Classroom identity for PAR, DAR, and storage aspect
Show students that PAR = DAR / (width/height) on a coded raster, including the 704-versus-720 ITU choice, without cancelling fractions by hand.
FAQ
What is the difference between pixel aspect ratio and display aspect ratio?
Display aspect ratio is the intended picture (4:3, 16:9). Pixel aspect ratio is the shape of one sample. Storage aspect is coded width/height. PAR = DAR / storage aspect. HD 1920×1080 at 16:9 has square pixels; 720×480 at 4:3 does not.
Why is 720×480 at 4:3 not 1:1?
The stored grid is 720/480 = 3:2, but the picture is 4:3, so PAR = (4/3) / (3/2) = 8/9. Decoders must stretch those samples. For the analogue-active 10:11 figure, pass width 704 instead of 720.
What happens if width, height, or a DAR part is zero or negative?
Every pixel and display-aspect dimension must be greater than zero; a zero or negative length cannot define a ratio and is not billed.
Why do some tables give 10:11 for NTSC 4:3 instead of 8:9?
Those tables are based on a width of 704 samples, not 720. Enter 704 as the width and the result is 10:11. The calculator always applies the formula to the exact resolution you type.
What is the storage aspect ratio of a video?
It is the stored width divided by the stored height. 1920×1080 is 16:9 in the grid, but 720×480 is 3:2 even when the programme is meant to look 4:3 or 16:9 on a television.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/image/pixel-aspect-ratio \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"width":1920,"height":1080,"dar_width":16,"dar_height":9}'const res = await fetch("https://api.kit.forhosting.com/image/pixel-aspect-ratio", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"width": 1920,
"height": 1080,
"dar_width": 16,
"dar_height": 9
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/image/pixel-aspect-ratio",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"width": 1920,
"height": 1080,
"dar_width": 16,
"dar_height": 9
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/image/pixel-aspect-ratio", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"width":1920,"height":1080,"dar_width":16,"dar_height":9}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"width":1920,"height":1080,"dar_width":16,"dar_height":9}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/image/pixel-aspect-ratio", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"width": 1920,
"height": 1080,
"dar_width": 16,
"dar_height": 9
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "image.pixel_aspect_ratio",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 15 |
max_megapixels | 12 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Any dimension that is zero or negative fails with invalid_input rather than a nonsense ratio.
What pixel aspect ratio is, and how it differs from display aspect ratio
Storage aspect ratio is simply coded width divided by coded height: 1920×1080 is 16:9 in the grid, but 720×480 is 3:2 in the grid even when the programme is meant to look 4:3 or 16:9 on a television. This page answers the search “pixel aspect ratio calculator,” not the search for a generic aspect-ratio reducer that only gcd-simplifies width:height.
Formula, input contract, and what happens when a dimension is invalid
Digit strings that parse to finite numbers are allowed so a pasted probe value does not need a second conversion. Integer-valued inputs inside the safe-integer range are reduced with Euclid’s algorithm so 1920×1080 at 16:9 returns PAR 1:1 and 720×480 at 4:3 returns PAR 8:9. Zero and negative dimensions fail with a message that every pixel and display-aspect dimension must be greater than zero; those failures are not billed. If you need the analogue-active ITU-R BT.601 table that quotes 10:11 for NTSC 4:3, pass 704 as width instead of 720 — the identity is always applied to the raster you supply, never to a hidden 704-sample assumption. Send four required finite numbers: width and height for the coded frame in pixels, and dar_width plus dar_height for the display aspect ratio (the 16 and the 9 in 16:9). Aliases pixel_width, storage_width, and w are accepted for width; pixel_height, storage_height, and h for height; display_width, dar_w, and aspect_w for dar_width; display_height, dar_h, and aspect_h for dar_height. The engine computes storage aspect as width / height, display aspect as dar_width / dar_height, and pixel aspect as display aspect / storage aspect, which is the same as (dar_width × height) / (dar_height × width). Missing fields, empty strings, non-numeric text, NaN, Infinity, and magnitudes above one trillion fail with invalid_input naming the field. On success the JSON echoes the four inputs, reports pixel_aspect_ratio as a stable twelve-decimal number, reports par_width, par_height, and the par string, reports storage_aspect_ratio with storage_aspect, reports display_aspect_ratio with display_aspect, sets square_pixels when PAR is 1, and restates the formula. Example: width 1920, height 1080, dar_width 16, dar_height 9 yields PAR 1:1 and square_pixels true. Example: width 720, height 480, dar_width 4, dar_height 3 yields PAR 8:9 ≈ 0.888888888889. Pricing for a successful item is a flat $0.002.
Where a pixel aspect ratio API earns its keep
Transcode farms that ingest mixed HD and SD packages can call the same contract for every file: if square_pixels is true, skip the anamorphic path; if not, scale by par_width:par_height before a square-pixel mezzanine. API usage draws from prepaid KIT balance at the published $0.002 per successful request; invalid input is not charged.
Integration use cases
Confirm HD and UHD pixels are square
Check that 1920×1080 or 3840×2160 at 16:9 returns PAR 1:1 and square_pixels true before skipping anamorphic handling in a transcode farm.
Technical questions
How do I calculate pixel aspect ratio from display aspect ratio and resolution?
PAR = (dar_width × height) / (dar_height × width), which is display aspect divided by storage aspect (width/height). POST the four positive dimensions to get the decimal, the reduced par string, and a square-pixels flag.
Is the pixel aspect ratio calculator free?
Yes. The in-browser runner uses the same library as the API and costs nothing. The API charges $0.002 per successful request from your prepaid KIT balance.