This is not specific to Chrome, but all browsers AFAIK. localStorage stores JavaScript Strings, which are UTF-16, meaning every character takes up 16bits of space. localStorage is limited effectively to 5MB, even on Chrome, it's just that Strings use a lot of memory in JavaScript. Note that this is not specific to JavaScript as it is the same in Java and C# for example.

The real issue I tried to solve in JavaScript is "how to represent a binary stream of data". The best answer I found is using Strings and using the 16-bits of all characters as storage.

 Just turn on gzip compression on your server and everything your server sends to the browser should be already gzip-compressed automatically, which is most likely much, much more efficient. You can see that if your server sends back a "Content-Encoding: gzip" into the http response to your browser. On Chrome, with the debugging tools turned on on the Network tab, you can see "Size/Content" for every request. Size is the actual number of bytes transferred while Content is the size of your uncompressed content.

 Thanks for the feedback. Thinking about it, LZString.compressToUTF16() seems much safer. Strings are sets of characters after all and who can predict what bugs an invalid character will trigger?

What is this chrome.storage.local you're using? If I read you correctly you store more than 5MB in it, so it must be something else than localStorage...

I found myself needing a Java implementation of this for pre-compressing data from a Java program before putting it on a static web-server. I decided to not rely on the internal automatic compression of most web servers to reduce complexity.

I wrote one and put it on my github here if anyone is interested: https://github.com/ownaginatious/lz-string-java

Just a word of caution though; I haven't done a very extensive amount of testing.

Well, for my specific application it was crucial that data get compressed before being sent to clients. From what I understand, if I were to rely on the internal gzip of the webserver, there is a chance that some devices wouldn't support it and would request the uncompressed version, which would waste a lot of bandwidth. This kind of "guarantees" that the compression will always happen. The content I'm serving is already stored as files compressed using your algorithm :). I also wanted a method of sending compressed data back to a webserver, which from what I can tell isn't natively supported by many browsers.

I know that's an awfully specific purpose, but I figure someone else out there might find a clever use for a Java implementation :)

Also, I forgot to mention before - great library! Out of all the JS compression libraries I've looked through, yours is by far the easiest to use!

 I have noticed this behavior with a localStorage full (5MB of packed strings) but it doesn't freeze, it just takes an awful lot of time rendering those weird strings. If you look at your task manager (or a top in a terminal) while trying to open the dev tools, you'll notice that one full core is crunching data for Chrome. This is the rendering part. while the rendering is done you can interact with your dev tools again.

Firebug exibits the same behavior 

This has to do (I think) with the handling of ultra-long strings coupled with the rendering of obscure UTF16 characters. With just a few kilobytes in localStorage everything is instantenuous.

Hi! I just wanted to leave a comment to say thanks for writing and releasing this - as you found out yourself, there really isn't anything else comparable that is readily available! I wanted to be able to reduce the size of JSON data stored on the server and decompress it on the client and this has enabled me to do just that. I was hosting on NeoCities which has a limit on the size of hosted sites - so relying on gzip for transmission was no good as that compresses the content delivered over the wire but doesn't reduce the backend storage requirements. Shameless plug: I wrote about this at JavaScript Compression (Putting my JSON Search Indexes on a diet). But really I just wanted to say thanks. So thanks! :)

 So, I got around to it and I tested my lib on nodejs. 

Your first example (using Base64String.compress) cannot work as Base64String is meant to compress base64 encoded content. Your string ("This is my compression test.") is not a valid base64 string. So it doesn't work. Basically Base64String is meant to reencode Base64 content (usually images). The rationale is that base64 takes up a full character to store 6 bits, while compressToUTF16 stores 15 bits per characters.

Your second example is more useful in that really, it doesn't work. It looks as if your compressed test string triggers a bug in either compressToUTF16 or decompressToUTF16. I'm working on it as soon as I get home.

 Oke thanks,

I will use is like this:

Serverside:
LZString.compressToUTF16(JSON.stringify({JSON:DATA}))

Clientside:
data = JSON.parse(LZString.decompressFromUTF16(data.compr));

Well test more later.

Something like that, using http://socket.io/ but I can only send UTF-8 (and no binary) :S
compressToUTF16() works still, but maybe not for all messages... 

Maybe I can create a UTF16 detection
IF( ContainsUTF16Char( LZString.compressToUTF16(JSON.stringify(args[1])) )){
  nocompression
}


 

Haha thanks for the information, I don't know very mucht about UTF8 / UTF-16

Socket.io don't support binary yet :(
If you think its easy to create a compressToUTF8() than I say :)

I quick compression check gives me this

msg = {data:'I say hello'}
console.log('no compression',JSON.stringify(msg).length)
compr = LZString.LZString.compressToUTF16(JSON.stringify(msg));
console.log('compression',compr.length);

no compression 22
compression 17
 

msg = {data:'I say hello, I can say more and more text so this is big'}
console.log('no compression',JSON.stringify(msg).length)
compr = LZString.LZString.compressToUTF16(JSON.stringify(msg));
console.log('compression',compr.length);