Content encoding

None of the encodings listed are involved with patent concerns.

Read below for further details.

Rasterized image encoding

Lossy still

As WebP is properly supported in every browser built for systems newer than Windows XP, and it offers better quality-to-size ratio than all JPEG encoders, it is considered the best fallback format. However, as JPEG XL exists as an all-around better universal image format, lossy images should also be encoded with JPEG XL whenever possible.

Compared to all other image formats, JPEG XL offers jawdropping image fidelity, unmatched quality-to-size ratio, proper progressive loading and better responsiveness. The cherry on top of JPEG XL would be its ability to losslessly transcode from existing JPEG files, offering about 20% size reduction with cheap JPEG lossless bitstream reconstruction, which paves its way to be a backwards-compatible drop-in replacement for image storage and distribution.

Things to take notice of:

• mozJPEG-fronted JPEG, while offering a good choice for backwards-compatibility, shouldn't be used unless necessary when size is a consideration. mozJPEG is generally superseded by jpegli.
• AVIF offers an advantage on size, when progressive support, boundary artifacts and codec performance (slower than all others multiple times) aren't in consideration.
• AVIF is observed to have fewer observable artifacts for images with a simpler shading.
• The reference AVIF settings provide a balancing point between JXL -d 1 and JXL -d 2.
• jpegli for JPEG from the JPEG XL team provides a reasonable front for backwards-compatible JPEG XL encoding. The estimated file size on fronted JPEG XL files are around 82.5% of the original JPEG files.

Explanations of image encoding uses:

• Delivery: Size-first with generally-acceptable quality.
• Delivery+: Balance between size and quality.
• Near-lossless: Shaving as much size as possible, while still being mostly indistinguishable, even when zoomed in at 200%.

The size ratio values listed below approach expectations on a large scale, based on experiments conducted on a relatively large scale with non-photographic images modelling 15.6% lossy inputs. Lossless inputs induce better (smaller) expectations, while lossy inputs tip the balance in reverse. Photograpic images will generally have a better (smaller) ratio than non-photographic images, but individual images may still yield greatly varied results.

The full feature set comparison chart is available on Cloudinary.

Lossless still

JPEG XL lossless and WebP lossless are mostly on par, either could be the better solution at times. For compatibility reasons, WebP lossless should always be offered, while JPEG XL lossless could be offered only when the resulting file is smaller than that of WebP lossless. AVIF lossless is currently consistently worse than either JPEG XL or WebP, as such it's not recommended at all.

Do not enable progressive encoding for JPEG XL lossless, or the resulting file will be several times bigger than PNG files.

Lossy animated

Lossy animated WebP is the current baseline for animated image sequences, while lossy animated AVIF offers the best quality against others by a wide margin. Lossy animated JPEG XL doesn't offer a significant advantage against WebP, and is currently beaten by AVIF.

Audio encoding

Lossy

When high sampling rates are required, choose Vorbis. When support for the Apple ecosystem is required, choose AAC-LC. Otherwise use Opus under all possible scenarios, but beware that Opus only supports sampling at 48kHz.

Below are the suggested bitrates under different scenarios, when encoding stereo audio content under either 44.1kHz or 48kHz. Audio content should be encoded with constrained variable bitrate (CVBR).

The AAC-LC encoder in question is libfdk_aac, being the best FOSS AAC-LC encoder out there. The only AAC-LC encoder better than libfdk_aac is Apple's Audio Toolbox, which is proprietary and not in consideration.

Keep in mind that the scenario under "basic" indicates that, all audio content encoded with provided parameters should be virtually indistinguishable from LAME-encoded MP3 files at 192kbps.

Lossless

Streaming lossless audio is generally considered a bad idea due to high bandwidth usage. It's generally more useful for archival purposes.

You should choose FLAC when...

• Browser support is needed.
• The target is severely underpowered.
• The target only supports FLAC for lossless audio compression.

You should choose WavPack when...

• You need a smaller file.
• Higher bit depth is needed (more than 24).

Compression

Web

Brotli should be preferred over gzip at all times. Static low-entropy content (e.g. plain text files) should always be pre-compressed, with or without the original uncompressed file available. For dynamic content compression, zstd at level 8 consumes less than half of the resources used for Brotli, all the while outperforming Brotli on the output size.

For static precompression, the original file can be omitted when the space is constrained, serving only precompressed blobs. When compatibility with other infrastructure isn't in consideration, precompressed gzip files can also be omitted, although it's not recommended in most cases. Zstd isn't suitable for static precompression, as even at compression level 22 it falls behind Brotli at its highest compression level. However, a recommendation is still available for reasonable reference.

Bundle

lzip is the de-facto standard of bundle compression, featuring good compression ratio with data recovery abilities. Quality should always set to 9, unless a lower quality value is proven to yield a better result for smaller files, or time constraints are set.

bzip2 or xz should only be considered for compatibility purposes.

Font

As practically all modern browsers support the WOFF2 font format, all required TrueType and OpenType fonts must be served as WOFF2 files instead. If for unspecified reasons that original files must be served, always consider precompression and avoid storing uncompressed files.