Add images to web pages without hosting them on servers [data URI]

Did you know you can embed images in HTML pages or blogs, right there within the page, without linking them to an external server? That means no uploading to any file server. The image data can be embedded right into the page. This is possible using data URI.

What is data URI?

Every resource, such as an image, JavaScript file, HTML file, or style sheet, has a URL that tells the browser from where to download the file. URL is short for uniform resource locator, which is a combination of a protocol and the address at which a given resource exists.

URI, which is short for uniform resource identifier, indicates a protocol for locating and retrieving a resource as well as additional information about the resource. That additional information may or may not be an address. If it contains an address, then the URI becomes a URL. If the URI contains data, it is then called data URI.

Data URI has the following format:


An example of a data URI code embedding an image in an HTML page is:

<img src="data:image/png;base64,
vr4MkhoXe0rZigAAAABJRU5ErkJggg=="  />

The gibberish you see in the above code is the Base64 encoding of the image.

To demonstrate, I have embedded an image below using data URI. This image is hosted nowhere. You can verify this by right clicking on the image and choosing Properties. (Internet Explorer 7 or 6 users will not see it.)

Why use data URI?

The biggest advantage of data URI is minimizing HTTP requests. When the data for the image is embedded within the document, the browser saves on HTTP request to fetch the image, which improves page loading. Data URI is useful when embedding small images like icons on a page. (See additional notes below).

Where do I get the Base64 code?

There are several online Base64 converters. This data: URI Generator works best.

Which browsers support data URI?

Data URIs are not supported by IE7 and lower. IE8 supports it but the data must be smaller than 32 KiB (KibiByte). Firefox, Opera, Safari, Chrome, and all of it’s variants support data URI. 

Additional Notes


  • HTTP request and header traffic is not required for embedded data, so data URIs consume less bandwidth whenever the overhead of encoding the inline content as a data URI is smaller than the HTTP overhead. For example, the required base64 encoding for an image 600 bytes long would be 800 bytes, so if an HTTP request required more than 200 bytes of overhead, the data URI would be more efficient.
  • For transferring many small files (less than a few kilobytes each), this can be faster. TCP transfers tend to start slowly. If each file requires a new TCP connection, the transfer speed is limited by the round-trip time rather than the available bandwidth. Using HTTP keep-alive improves the situation, but may not entirely alleviate the bottleneck.
  • When browsing a secure HTTPS web site, web browsers commonly require that all elements of a web page be downloaded over secure connections, or the user will be notified of reduced security due to a mixture of secure and insecure elements. HTTPS requests have significant overhead over common HTTP requests, so embedding data in data URIs may improve speed in this case.
  • Web browsers are usually configured to make only a certain number (often two) of concurrent HTTP connections to a domain, so inline data frees up a download connection for other content.
  • Environments with limited or restricted access to external resources may embed content when it is disallowed or impractical to reference it 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.
  • It is possible to manage a multimedia page as a single file.
  • Email message templates can contain images (for backgrounds or signatures) without the image appearing to be an "attachment".


  • Data URIs are not separately cached from their containing documents (e.g. CSS or HTML files) so data is downloaded every time the containing documents are redownloaded.
  • Content must be re-encoded and re-embedded every time a change is made.
  • 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.
  • Base64-encoded data URIs are 1/3 larger in size than their binary equivalent. This overhead is reduced to 2-3% if the HTTP server compresses the response using HTTP’s Content-Encoding header.
  • Data URIs make it more difficult for security software to filter content.

Source: Wikipedia

Be the first to comment

Leave a Reply

Your email address will not be published. Required fields are marked *