Cookie-less Session Variables in JavaScript

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 window.name property (or window.top.name if you’re using multiple frames).

It’s rare for developers set the window.name 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:


window.name = "This message will survive between page loads.";

Now add the following code to any other page:


alert(window.name);

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 window.name 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 window.name for storing secure data (unlikely to be a major problem for a client-side-only temporary data store).
  2. window.name 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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.primalskill.com feketegy

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

  • http://www.clerkendweller.com/ Clerkendweller

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

    Storing data in the window.name 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 window.name 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.

  • http://www.kellishaver.com/ KelliShaver

    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 window.name property to store a ‘session id’ (wink-wink, nudge-nudge) that can tally back to proper server side persistence.

    That window.name 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 “window.name” can hold _megabytes_ of data. Weird, cool, prone-to-abuse…

  • http://www.dmgx.com Michael Morris

    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 window.name 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.

  • http://www.optimalworks.net/ Craig Buckler

    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.

  • http://www.arwebdesign.net samanime

    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

  • http://www.brothercake.com/ brothercake

    I’ve always considered the ability to save large amounts of data to window.name 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 :)