The data URI scheme is a URI scheme that provides the ability to include data items in-line in a web page, as if they were being referenced to as an external resource. They tend to be simpler than alternative inclusion methods, such as MIME with cid: or mid:. data URIs are a form of Uniform Resource Locators, although they do not actually remotely locate anything. The data URI scheme is defined in Internet Engineering Task Force standard RFC 2397.
Web browser support
data: URIs are currently supported by the following web browsers:
HTTP request and header traffic is not required for embedded data, so data: URIs use fewer network resources whenever the overhead of encoding the inline content as a data: URI is smaller than the HTTP overhead.
Web browsers are typically configured to use a maximum of two concurrent connections to a server [as per RFC], 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.
 secure environments commonly require full secure streaming for all  requested elements, or the user will be notified of a mixed secure and insecure elements environment.  requests have significant overhead over common  requests. Embedding data in data URIs can improve speed more significantly in this case.
It's possible to manage a multimedia page as a single file.
Embedded content must be extracted and decoded before changes may be made, then re-encoded and re-embedded afterwards.
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.
Browsers may limit URI lengths, creating an effective maximum data size. For example, URIs in previous versions of Opera had limits of 4kB, and 32kB for IE8 Beta 1
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.
Under certain conditions there are some possible additional disadvantages:
Base64-encoded data: URIs are roughly 33% larger in size than their binary equivalent.
URL-encoded data: URIs can be up to 200% larger (in extreme cases) than the original text content.
The encoding is indicated by ;base64. If it's present the data is encoded as base64. Without it the data (as a sequence of octets) is represented using ASCII encoding for octets inside the range of safe URL characters and using the standard %xx hex encoding of URLs for octets outside that range. If is omitted, it defaults to text/plain;charset=US-ASCII. (As a shorthand, the type can be omitted but the charset parameter supplied.)
An HTML fragment embedding a picture of a small red dot:
The data: URI permits whitespace, but a bug in old versions of Mozilla (2001 and earlier) prevented such URIs from being parsed.
Because base64-encoded data URIs are not human readable, a website author might prefer the encoded data be included in the page via a scripting language such as PHP. This has the advantage that if the included file changes, no modifications need to be made to the HTML file, and also of keeping a separation between binary data and text based formats. Disadvantages include greater serverCPU use unless a server-side cache is used.
Similarly, if CSS is processed by PHP, the above function may also be used:
In either case, client or server side features/UA detection/discrimination systems, (like conditional comments) may be used to provide a standard http: URL for Internet Explorer and other older browsers.
An alternative for attaching resources to an HTML document is MIME HTML, usually found in HTML email messages.