By Craig Buckler

Cookie-less Session Variables in JavaScript

By Craig Buckler

the (JavaScript) Cookie MonsterCookies may be delicious delicacies, but they can leave a nasty taste if you don’t cook them correctly! Cookies can be blocked by the user, storage space is limited to four 20Kb cookies per domain, only strings can be used, paths can cause confusion, and the data is normally passed as plain text in the HTTP header. Often, cookies can be overkill for client-side-heavy applications that need to save temporary state data.

Fortunately, there is a solution that allows you to store JavaScript data within the browser. The data is retained between page loads, it’ll survive page back/next events (even away from the domain), it does not require plugins or off-line storage facilities, it’ll hold at several megabytes of information, it is never transmitted to the server, and works in every browser. Bizarrely, it works by exploiting the property (or if you’re using multiple frames).

It’s rare for developers set the property. Generally, it’s only required when you’re manipulating frames or pop-up windows. Even though I’d hope you weren’t doing that, you do not normally need to define a name for an application’s starting window. Although the name property is still a string, it can hold several megabytes of data. Some versions of Opera limit it to around 2Mb but most browsers offer 10MB or more.


It’s easy to try for yourself. Insert the following JavaScript code into a page on your site: = "This message will survive between page loads.";

Now add the following code to any other page:


Navigate from the first page to the second and you’ll find that the message data is retained.

As normal, there are a number of caveats:

  1. The property can be analysed and changed if you navigate to page on another website. That’s easily thwarted by not providing external links within your application’s main window. However, to be on the safe side, don’t use for storing secure data (unlikely to be a major problem for a client-side-only temporary data store).
  2. can only store strings. What if we need to save other data types or even complex objects? Serialization is the answer and, fortunately, we have already developed cross-browser code to generate JSON strings from any JavaScript object.

See also: How to Write a Cookie-less Session Library for JavaScript.

  • Why not store persistent information in a database and then simply save the session id in the cookie?

  • Feketegy’s suggestion is the correct way to solve the difficulties mentioned.

    Storing data in the property is going to be a recipe for disaster. The handling of cookies has inbuilt protections such as preventing other sites from reading cookies set by another, expiry at a set point in time and the ability to prevent the cookie being visible to client-side code. If people start using the property, we’ll see a whole raft of new security and privacy faults.

  • HSN

    Clerkendweller is right. Even the author saying that the option should not be used to store secure data, I’d never use this hack.
    If you need to pass some megabytes you should probably do the way feketegy said and start thinking about use XML and/or SOA. Also users can disable support to javascript in any browser.

  • Agreed. This is nothing but a cheap trick and a bad idea. It has no actual practical application that could be considered at all secure or usable for anything other than looking cute.

  • RichardGreen

    Sorry to disagree with the other posters, but I think this is a good idea.

    Not precisely as the author explains, I personally would (if-and-only-if cookies were not available) just use the property to store a ‘session id’ (wink-wink, nudge-nudge) that can tally back to proper server side persistence.

    That would store a session id unique to the domain and it doesn’t matter if another site tampers with it (you could encrypt said ID and HMAC secure it to be doubly secure and thus preventing using someone else’s ‘session’)

  • Dave Transom

    Good and bad aside, it’s certainly interesting to even think that “” can hold _megabytes_ of data. Weird, cool, prone-to-abuse…

  • If you have a client application that needs to store that much information consider using the database object of Google Gears.

  • Dan Dorman

    This is a neat-if-not-exactly-practical idea. The real Achilles heel of this trick to me is that it won’t necessarily work on a Web-aware web site. Indeed, this seems like the sort of thing you’d want to keep to yourself, since once everybody starts using it–poof–there goes its utility. But again, the author implies it should really be used in self-contained apps anyway. Unless some kind of quasi-standard governing its use appears (JSON-namespaced, perhaps?), and then everyone can play together nicely ;). Heck, if all you’re using it for is client-side caching anyway, it’s not like anything mission-critical is gonna blow up on you.

    Kudos for a clever hack. I’ll have to look for some places I can use it.

  • As mentioned, this method is only suitable for storing temporary JavaScript session-only data. That can be useful in heavy client-side applications. For example, you could store temporary option information (draggable widget positions, ‘frame’ locations, etc.). Or perhaps you have an auto-complete search box — strings could be fetched using Ajax, then cached locally so that same request never need be called again. Logging and debugging could also be another use.

    It’s not a substitute for cookies or offline data stores; it’s an alternative for JS-only session data.

  • DomAJAX

    * “Why not store persistent information in a database and then simply save the session id in the cookie?”

    Well to me it sounds like the whole point is being able to NOT use cookies. Especially in this day and age where users are so paranoid about cookies and many turn them off. I came to this blog in search of cookie alternatives (to track sessions specifically).

    * “This is nothing but a cheap trick and a bad idea.”

    To say that its a cheap trick is a little harsh. It may not offer all the benefits of cookies but it does offer other things like extra storage space. I dont think author is putting this out as the “be all and end all solution” its just another tool in our toolkit that we can use if we want/need to. For me, it’s not exactly what I’m looking for but none the less I still think to myself “hey thats a neat trick if I need it”.

    * Regarding the security aspects of using such an object… ever thought of creating an ajax service to encrypt and decrypt data (where all keys and logic are hidden)? With such a thing in place then data can encrypted before stored here quite safely I would expect, and then decrypted after being read out. Of course this approach has its problems but then which cookie-workaround out there doesn’t? (for e.g. url-rewriting exposes the session too much for my liking).

    * On a personal note, don’t be so quick to scorn – its great to be able to foresee problems but as solution providers, developers need to be see the possibilities as well – else we all get stuck doing the same old thing that everbody else does and the web never evolves.

  • One thing that really bugs me about a lot of “web elites” is they always look at something and if it isn’t a swiss-army-useful-in-all-situations tool, they just immediately disregard it.

    All the examples of bad I saw were talking about big AJAX/database/PHP/MySQL powered full-fledged sites. What about smaller applications? What about a game, written in Javascript? What about some Javascript-powered application that is meant to be saved and run offline?

    As others said, this is a good tool to have in your toolbelt, not something you’re going to use in every single project. There are some limited applications that this would be perfect for. Not every bit of data on a computer needs to be quintuple-encrypted to prevent data theft. It’s not the end of the world if someone sees the your saved game data for a Javascript-based RPG. =p

  • I’ve always considered the ability to save large amounts of data to to be a security bug. You’d better hope that not many people use this hack, because if a threshold is reached and functional exploits start to make their way around, this bug will be fixed quick sharp.

  • Dean

    idiot. just because you can doesn’t mean you should – at all.

  • kurole

    I never thought i can use name property for storing data. though I am not going to use it but still it is nice tutorial

  • Nnnnnnnnnnnn

    thnx :)

Get the latest in JavaScript, once a week, for free.