Skip to content

Instantly share code, notes, and snippets.

@paulirish
Last active January 31, 2024 14:36
Star You must be signed in to star a gist
Save paulirish/5558557 to your computer and use it in GitHub Desktop.
a brief history of detecting local storage

A timeline of the last four years of detecting good old window.localStorage.


Jan Lenhart, bless his heart contributed the first patch for support:

October 2009: 5059daa

(typeof window.localStorage != 'undefined')

Simplicifations

November 2009: 15020e7

!!window.localStorage

If cookies disabled in FF, exception. Softer detect

December 2009: 1e0ba91

!!('localStorage' in window)

If DOM storage disabled in IE, window.localStorage is present but === null.

January 2010: d8947c9

(localStorage in window) && window[localStorage] !== null

FF with dom.storage.enabled = false throws exceptions

July 2010: ef2c47

try {
  return ('localStorage' in window) && window[localstorage] !== null;
} catch(e) {
  return false;
}

more shit because of FF exceptions

December 2010: c630c39

try {
    return !!localStorage.getItem;
} catch(e) {
    return false;
}

iOS private browsing fucks everyone!!!

October 2011: 5e2fa0e

try {
    return !!localStorage.getItem('getItem');
} catch(e) {
    return false;
}

stronger full capability test for localstorage with iOS private browsing protection

October 2011: a93625c

try {
    localStorage.setItem(mod, mod);
    localStorage.removeItem(mod);
    return true;
} catch(e) {
    return false;
}
@gr2m
Copy link

gr2m commented May 13, 2013

This is awesome, great summary! I think I went trough every single step myself :)

@djhopper01
Copy link

This is great. Thank you for this.

@RodrigoAyala
Copy link

Great story. Code is always on evolution and improvement, and this is a great example. Thank you for this!

@pmuellr
Copy link

pmuellr commented May 14, 2013

reminds me of IEFBR14 - see the note from John Pershing near the bottom of the article

@toobstar
Copy link

I have a IE9 VM running on mac & this isn't working. Setting & removing a value works OK but when you fetch it out you get a null. An improvement could be actually testing that you can retrieve value and it matches input.

@DominoPivot
Copy link

Just in case anyone wonders even though it was an old comment, toobstar did something wrong because I tested IE9 on a VM and it works fine.

@mpavel
Copy link

mpavel commented Apr 18, 2016

According to MDN (https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API), this is now best done with:

function storageAvailable(type) {
    try {
        var storage = window[type],
            x = '__storage_test__';
        storage.setItem(x, x);
        storage.removeItem(x);
        return true;
    }
    catch(e) {
        return false;
    }
}
if (storageAvailable('localStorage')) {
    // Yippee! We can use localStorage awesomeness
}
else {
    // Too bad, no localStorage for us
}

Lovely :)

@Download
Copy link

Download commented Aug 27, 2016

Actually, I based that sample on the code and history presented in this very gist. So thank you all who contributed to it!

EDIT: I released that snippet as an NPM package so you don't have to copy-paste it... Also we can maintain it if stuff needs to change to it in the future,

https://www.npmjs.com/package/storage-available

@matthewadowns
Copy link

On a related, if you're looking to shim localStorage, there are great vanilla JS solutions:

Using cookies:
https://developer.mozilla.org/en-US/docs/Web/API/Storage/LocalStorage

Using in-memory:
https://gist.github.com/juliocesar/926500

@tigr5
Copy link

tigr5 commented Dec 2, 2017

by way of interest, there's a slight difference in the current version of the code put in the comment above from mpavel (commented on Apr 18, 2016) regarding the Web Storage API 'Basic Concepts' page section entitled:
"Here is a function that detects whether localStorage is both supported and available:"
mpavel in April 2016 put this:

catch(e) { return false; }

today in December 2017 this snippet reads thus:
catch(e) { return e instanceof DOMException && ( // everything except Firefox e.code === 22 || // Firefox e.code === 1014 || // test name field too, because code might not be present // everything except Firefox e.name === 'QuotaExceededError' || // Firefox e.name === 'NS_ERROR_DOM_QUOTA_REACHED') && // acknowledge QuotaExceededError only if there's something already stored storage.length !== 0; }

@tobsn
Copy link

tobsn commented Dec 27, 2017

@tigr5

like this?

function storageAvailable(type) {
	try {
		var storage = window[type],
			x = '__storage_test__';
		storage.setItem(x, x);
		storage.removeItem(x);
		return true;
	}
	catch(e) {
		return e instanceof DOMException && (
			e.code === 22 || e.code === 1014 ||
			e.name === 'QuotaExceededError' ||
			e.name === 'NS_ERROR_DOM_QUOTA_REACHED'
		) && storage.length !== 0;
	}
}

@Download
Copy link

The first lines inside the try block might already fail with an exception:

var storage = window[type], // could throw if storage is disabled (Firefox)
    x = '__storage_test__';
// storage might be null here.... (Internet Explorer)
storage.setItem(x, x);  // would throw if storage is null

Just read back in this gist. FF will in some cases throw an exception if you touch window.localStorage.... IE might give you a null object... So I don't see how the extra checks for the exception type help. In fact I think they actively break the code.

The way I approach it, if simply setting and removing an item from storage fails in any way then storage is not available.

I stand by my original version. I have given up on maintaining the MDN page. People keep coming by and 'fixing' the code sample. I have even seen people change it to samples that don't even run at all or always return true etc. My original sample works fine and does not need those extra lines imho. In fact the code becomes less reliable because of those extra lines.

@SebAlbert
Copy link

@Download The modified catch block will still return false except when the caught error happens to be "over quota error" (which is checked in four different ways), which means that the storage system is actually available, but just exhausted, and thus the (arguably) correct answer is still true

@douglasnaphas
Copy link

Does this gist apply equally to sessionStorage?

@Download
Copy link

Yeah, in fact I think it does. Which is why that storageAvailable function accepts a type parameter. So you can use it for both localStorage and sessionStorage.

@targumon
Copy link

targumon commented Feb 3, 2020

In case you want to save some bytes, instead of:

    localStorage.setItem(mod, mod);
    localStorage.removeItem(mod);

you can do this:

    localStorage.x = 1;
    delete localStorage.x;

@devinrhode2
Copy link

Can anyone provide insight/their opinion on what are good uses cases for sessionStorage? https://stackoverflow.com/questions/8498357/when-should-i-use-html5-sessionstorage

@Download
Copy link

@devinrhode2 I think sessionStorage is great for any data you want to share across pages and tabs for the duration of the browsing session. It will be wiped as soon as the browser closes.

@targumon
Copy link

@devinrhode2 I think sessionStorage is great for any data you want to share across pages and tabs for the duration of the browsing session. It will be wiped as soon as the browser closes.

Wrong.
"Opening multiple tabs/windows with the same URL creates sessionStorage for each tab/window." (source: mdn)

@Graciano1997
Copy link

I have tried this !!('localStorage' in window) === true

and ('localStorage' in window)=== true 🙏 very simple

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment