image/jpeg, image/png
Still the two main universal formats for static images, as of 2016.

These should only be used if the original data itself was in that format. For static pixel data converted from some other format, Raw Pixels should be used.

• width, height: Pixel dimensions so that, for example, an <img> can be set to the correct size before the data is loaded

image/gif
GIF should only be used if the original data is already in this format, or if the data represents an animation that can be losslessly converted to a GIF animation. Meaning, the animation should:

• be fundamentally pixel-based (and not, for example, vector-based)
• loop from beginning to end
• never use more than 256 colors
• need only 1-bit transparency
• require no sound, interactivity, branching, or other advanced feature

It should also probably be no more than a few seconds long, but this is more of a general guideline than a deciding rule.

In particular, static images should never be re-encoded as GIF from some other format -- use Raw Pixels instead.

• width, height: Pixel dimensions so that, for example, an <img> can be set the correct size before the data is loaded

image/svg+xml
The instructions to construct a vector-based image, in an <svg> XML document.

• width, height: Pixel dimensions so that, for example, an <img> can be set the correct size before the data is loaded

image/x-pixels; format=r8g8b8a8
This format is compatible with the .data array in an ImageData object created for a <canvas>.

• width: The number of pixels wide the image is. This must be defined here, because the data itself can't tell us, it's just a stream of pixels. It could be a very wide image 1 pixel tall, a very tall image 1 pixel wide, or anything in between.

• stride: The width in pixels of a full scanline. If not specified, it is assumed to be the same as width.
• height: The number of pixels tall the image is. (This can be calculated by dividing the total length of the data by stride, so it's not absolutely required, but why not include it anyway.)

Browsers will certainly load a BMP, but it's still not included as a "browser-ready" type for these reasons:

• to support esoteric/archaic BMP variants that browsers may not support
• in case support is dropped altogether one day
• most BMPs are essentially just a wrapper for a bunch of uncompressed pixel data anyway (and some are even a wrapper for image/png or image/jpeg, but that's rare)

The set of supported audio types can only be determined per-browser by using the .canPlayType() method on an <audio> element.

audio/x-samples; format=f32
This format is compatible with the sample arrays given to .copyToChannel()/.copyFromChannel() methods of AudioBuffer.

• rate: sample rate, e.g. 44100, 22050

• channel:
• left
• right
• mono (default)
• loop:
• true
• false (default)
• the number of samples to loop back from the end

The set of supported audio types can only be determined per-browser by using the .canPlayType() method on an <video> element.

text/plain
A text document with no styling or hyperlinks, and manual word-wrapping.

• display-width: intended width, in characters, for the document to be displayed

text/html
A text document with styling, internal hyperlinks, and/or requires automatic word wrapping.

Embedded images and other resources are likely to be Base64-encoded. ((TODO: investigate using blob URLs, or "serving from" a Volume -- service workers?))