Jump to content

data URI scheme

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Boborok (talk | contribs) at 15:59, 10 May 2006 (rv, that one line could have been reverse engineered etc, i don't think that's a violation). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


The data: URI scheme, as defined by IETF standard RFC 2397, is a URI scheme that allows inclusion of small data items inline, as if they were being referenced in an external resource. They tend to be far simpler than alternative inclusion methods, such as MIME with cid: or mid:. According to the wording in the RFC, data: URIs are in fact URLs (Uniform Resource Locators), although they do not actually locate anything.

The scheme is currently supported by Mozilla (and its derivatives, such as Firefox), Opera, Safari and Konqueror. Microsoft's Internet Explorer, as of version 7, does not support data: URIs. Early versions of Internet Explorer treated unrecognised about: URIs as HTML source, so something like about:<b>bold</b> in these versions was broadly equivalent to data:text/html,<b>bold</b> in browsers that support data: URIs

Advantages

  • HTTP headers are not required for embedded data, so data: URIs can use fewer network resources when the overhead of encoding the inline content as a data: URI is smaller than the HTTP headers that would otherwise be required.
  • Web browsers are typically limited to four concurrent connections to a server, so inline data frees up a download connection for other content.
  • Browsers manage fewer cache entries for a file that contains data: URIs.
  • Environments with limited or restricted access to external resources may embed content when it is disallowed or impractical to reference externally. For example, an advanced HTML editing field could accept a pasted or inserted image and convert it to a data: URI to hide the complexity of external resources from the user.

Disadvantages

  • Embedded content must be extracted and decoded before changes may be made, then re-encoded and re-embedded afterward.
  • Base64-encoded data: URIs are roughly 33% larger in size than their binary equivalent.
  • URL-encoded data: URIs can be up to three times larger (in extreme cases) than the original text content.
  • Information that is embedded more than once is redownloaded as part of the containing file, and thus does not benefit from the browser's cache.
  • Browser limits to URI length provide a maximum data size. For example, URIs in Opera used to have limit of 4kb.
  • Data is included as a simple stream, and many processing environments (such as web browsers) may not support using containers (such as multipart/alternative or message/rfc822) to provide greater complexity such as metadata, data compression, or content negotiation.

Format