Take the 2-minute tour ×

I know you can include css and images, among other file types, which have been stored in base64 form within a javascript file. However, those are decently huge... and gzipped, they shrink down a LOT, even with the ~33% overhead from base64 encoding.

Non-gzipped, images are data:image/gif;base64, data:image/jpeg, data:image/png, and css is data:text/css;base64. What mime type can/should I be using, then, to include css or image data URIs which are gzipped? (Or if gzip+base64 can't work, is there any other compression I can do to bring down the string's size, while still keeping the data stored within the javascript?)

..edit.. I think the question is being misunderstood. I am not asking if I should include gzipped base64 strings within javascript. Yes, I know it's best, in most cases, to gzip the javascript and other files on the server end. But that is not applicable for a userscript; a userscript has no server, and consists of only a single file. Firefox allows a @require directive, but Opera and Chrome do not, and local file security issues come into play with loading any local files. Thus anything needed by the script has to be either: 1) on the web (slow) or 2) embedded in the userscript (big).

Now this question assumes that big is preferable to slow, but that big does not have to mean we totally ignore just how big; if it can be smaller, that's an improvement.

So assuming that a base64 string is embedded in javascript, the question is how to make it into something meaningful.


1) atob() can convert raw base64-encoded gzip to raw gzip within javascript. (atob does not need to know the mediatype). The question then would be how to decompress that raw gzipped css or image file so that the resulting output can be fed into the document.

or 2) given the proper mediatype, browsers at least theoretically (per the datauri RFC) should be able to load any file directly from a datauri. "" is sufficient to load a non-gzipped css stylesheet. The question here would be what link type attribute and datauri mediatype combination should work (and which browsers would it work for)? Preferably, for a userscript, this would be a combination that works in Opera, FF, and Chrome.

share|improve this question
the base64 encoding has 33% overhead. –  Dan D. Jan 28 '12 at 21:00
Fixed. :) I don't really care about the overhead's size; for a userscript, size isn't as important to me as keeping everything to one single distributable file. But it'd be nice to keep the base64 blobs as small as I can, hence this Q. –  BrianFreud Jan 28 '12 at 21:04
Wouldn't you want to just include the base64 in your JS, and gzip the JS? –  sdleihssirhc Jan 28 '12 at 21:06
Not in a userscript. –  BrianFreud Jan 28 '12 at 21:07
if size is not that important for you, why do you want to reduce vhe base64 blob size: is it for development readability? –  Mathieu Jan 28 '12 at 21:25

1 Answer 1

In HTTP, compression is most often only applied for transmission to reduce the payload that is to be transmitted. This is done by the Content-Encoding header field.

But the data URL scheme is very limited and you can only specify the media type:


Although you could use a multipart message, most user agents don’t support them in data URLs. It would also be questionable whether the additional data to describe such a multipart message wouldn’t be more than the data you safe by compressing the actual payload.

So compressing the data in a data URL is possible in theory but impracticable. It is better to simply compress the whole document the data URL is embedded in.

share|improve this answer
This doesn't address the question, nor is it correct. It's fully legal, per the dataurl RFC, to encode just about anything. Nor does gzip require a multipart mime type; application/gzip is fully legal, for example. Nor, for that matter, is base64 the only permitted encoding - base64 is not even the default encoding (US-ASCII is). –  BrianFreud Jan 28 '12 at 22:00
Of course you can wrap any data in a data URL by specifying the corresponding media type. And you can also do it with application/gzip data. But then the data is handled as application/gzip data and not as CSS or JavaScript or whatever. And the Base64 encoding is also only used for wrapping to have a URL-safe charset the data needs to be encoded according to the URL-encoding. –  Gumbo Jan 28 '12 at 22:16
Sure, but again, this does not address the question of how to include a gzipped css file. I haven't seen a complete implementation, but I've heard of it being done, somehow, via an XMLHttpRequest with overriden mime type, sending the gzipped string through a dummy XMLHttpRequest not so the data goes anywhere, but so that the browser then decompresses it into the responseText. The pseudofunction I've seen was: –  BrianFreud Jan 28 '12 at 22:40
function read(fileName) { var xmlhttp = new XMLHttpRequest(); xmlhttp.open("GET", fileName, false); xmlhttp.overrideMimeType('text/plain; charset=x-user-defined'); xmlhttp.send(null); return xmlhttp.responseText; } –  BrianFreud Jan 28 '12 at 22:40
So you send compressed data to the server to decompress it? What would that be good for? –  Gumbo Jan 28 '12 at 22:44

Your Answer


