Choosing Output Resolution: 480p to 1080p by Use Case
Most people pick 1080p by instinct "higher is better" — but resolution is first a question of who watches, where. Reverse-engineer the tier from the actual viewing window and save half the size.
Resolution is a display-window matching problem
Perceived sharpness depends on matching source resolution to the actual display window: 1080p on a 1080p screen is pixel-perfect; the same file inside a 480p chat thumbnail discards the extra pixels — it looks the same as a 480p source at four times the size. Choosing resolution is guessing how large the window your viewer actually sees is.
The reverse also holds: a source below the window gets upscaled and blurred. The principle: never below the common viewing size, never above what the destination benefits from.
The scenario decision table
Chat previews and feed grids: 480p is enough — small, fast, perceptually lossless. General sharing and most platform feeds: 720p is the safe tier on phone-height viewing. Embedded articles, standard uploads, web players: 1080p, clean at fullscreen. TVs, casting, presentations: keep source resolution — let the player scale.
Archiving deserves its own rule: do not keep 4K "just in case" — when the big-screen moment comes, re-derive a copy from the archive. Archive resolution equals the most common way the file will actually be watched, not the highest possible quality.
Execution notes for downscaling
Downscale proportionally (both axes together) or the frame distorts; prefer the Lanczos algorithm for sharpness retention. Fold the scale into the compression pass when the tool offers it — one encode instead of two.
One trap: regretting a 1080p-to-720p decision and upscaling back. Upscaling recovers nothing — interpolation guesses the pixels and you pay size for them. Resolution downgrades are one-way; decide by asking where the audience actually watches.