That won't fit in cookie space... this is really for redundant controls for session/access tokens etc... anything large like that you're better off using caching and a service worker to handle repeated requests. Also, cookies are sent with every request to the server, and I don't think you'd want the user sending 10MB to your server for every request.

Also, if you are storing larger strings in local/sessionStorage, websql or indexdb, you should use lz-string[1] to try to minimize storage impact.

Aside: if you want something with a nicer interface for underlying storage you may want to look at pouchdb[2], which has a localized couch interface and supports remote synching to coudchdb, which is pretty nice.

[1] https://github.com/pieroxy/lz-string [2] https://pouchdb.com/

Yeah, about those cookies - I don't want them (https://github.com/gruns/ImmortalDB/issues/6). I just want to permanently store large data in the browser. ImmortalDB sounded like the right thing to abstract away everything and make it sticky.

You can tell it not to use cookies, to get around the problems of them being more limited in size and being sent on each request so wasting bandwidth.

I'm guessing a mix of localstorage and sessionstorage isn't al that useful (I can't imagine a circumstance where localstorage is being cleared when sessionstorage isn't also or hasn't already been) but localstorage+indexeddb might give you some useful level of protection.