Preferred formats

Technical decisions I usually make.

Character encoding

UTF-8, because it supports Unicode without sacrificing ASCII compatibility.

Dates

ISO 8601, because it's better than the alternatives.

Information units

Base 10 (i.e. 1 kB = 1000 B), because it's more intuitive for people using base 10 numbers (everyone).

Line endings

LF, because everyone uses it (except Windows).

Physical units

Metric, because it's easy to do conversions in it.

For borders, shadows, and icons

px, because those are usually small, and it's nice when they're pixel-perfect.

For font sizes

em, because it handles nesting, and it's possible to adjust globally by changing the :root font size. When used for :root itself, it also respects the user's system font size.

For element sizes and spacing

rem, because it's possible to adjust globally without depending on the font size of a particular element, which improves consistency.

For viewport media queries

em, because it scales with the user's system font size. It doesn't make sense to use rem here because media queries don't respect the :root font size.

For filenames and interactive commands

kebab-case, because it's easy to type (unlike snake_case) and easy to read (unlike camelCase).

For captions of UI elements

For titles of articles, videos, and their sections

Sentence case, because Title Case makes them look noisy, especially when they're long and there are many of them in a row.

For names of programming projects

Title Case or kebab-case, depending on which one looks cooler, because that's what nerds do.

For titles of other works of art

Title Case, because those are usually short, and it looks cool. When they aren't short, it also works because it adds comedic value.

Image dithering

Floyd-Steinberg, because it's reasonably good and widely supported.

Video deinterlacing

bwdif, send_field mode in FFmpeg, because putting each field on a separate frame mimics what happens when you look at a real CRT.

For most use cases

Linear RGB, because it correctly models the blending of the light coming from the display (unlike gamma encoded RGB).

For upscaling

Gamma encoded RGB, because it doesn't make ringing artifacts worse (unlike linear RGB).

For picking palettes

Oklch, because it handles hue better than CIELCh.

For most use cases

Catmull-Rom, because it's decently sharp, has no positive ringing artifacts (negative ringing is tolerable) and no blocking artifacts (unlike Lanczos which doesn't satisfy the partition of unity).

For blurring

Quadratic B-spline, because it's very close to Gaussian but bounded and cheaper to compute.

For slight transformations

For downscaling pixel art and screenshots

Robidoux NoHalo or linear, because they completely avoid ringing artifacts without blurring too much.

For upscaling pixel art and screenshots

Nearest neighbor, because it preserves sharp rectangular pixels.

When dealing with non-square pixels, make sure to account for their aspect ratio. For example, the NES has a resolution of 256x240 pixels, but it's stretched to fill a 4:3 display. As such, when upscaling NES footage to 1080p, the resulting resolution should be 1440x1080, not 1152x1080.

If you want to avoid uneven pixel sizes, upscale by an integer factor first (with nearest neighbor), then downscale by a fractional factor (with the downsampling filter of your choice).

Lossy

Opus, because it blows everything else out of the water.

Lossless

FLAC, because it's widely supported.

Digital

Markdown, because it can be produced and read in a plain text editor.

Printed

PDF, because Office documents are too fragile.

For most use cases

tar + Zstandard, because it's both fast and compresses well.

For archiving already compressed files

tar, because it doesn't compress unless you ask it to.

For maximum compatibility

ZIP, because it's widely supported.

Vector

SVG, preferably without editor-specific metadata, because it works on the Web.

Lossy

Progressive JPEG, preferably encoded with Jpegli, because it's widely supported.

Lossless

PNG, preferably encoded with Oxipng, because it has wider support and a wider feature set than lossless WebP (despite lower efficiency).

For long term photo storage

JPEG XL, because it can be losslessly transcoded from JPEG and back.

Lossy

AV1, preferably encoded with SVT-AV1, because it blows everything else out of the water.

Lossless (if you need it for some reason)

FFV1, because it's fast and simple.

For production and storage

Matroska, because it can fit anything inside, including FLAC and FFV1.

For distribution

WebM, because it works on the Web.