JavaScript Variable Checking Guides

This JavaScript article tutorial guides you how to check type of JavaScript variables. This JavaScript tutorial guide contains full-completed JavaScript example codes and comments, it's very easy to follow, please go to the full-post page for details.

Other JavaScript tutorials for beginners:
- JavaScript OOP Tutorial for Dummies
- 10 Tiny JavaScript Snippets for Good Beginners
- Top 10 Best JavaScript eBooks that Beginners should Learn
- The basics of Javascript for beginners

Sampled by ©

In general it’s a good practice to check for the existence of something before blindly using it by faith and hoping it works. There are various times during the execution of scripts when a variable may not be defined, it may be null, or it might be an empty string. These are three things that are easily conflated. A good way to look at this is thinking of these as having increasing levels of existence (getting a bit philosophical here for a moment…):

foo0;             // existence level 0 (creates the error "not defined")
var foo1;         // existence level 1 ("undefined" - variable declared but not defined/initialized)
var foo2 = null;  // existence level 2 (variable initialized, but isn't an Object, Number, String, etc)
var foo3 = "";    // existence level 3 (variable initialized to an empty String)
var foo4 = "bar"; // existence level 4 (variable initialized to String "foo")

Generally it would be handy if we had some way to filter out everything but the very last line. We simply want to check for these cases without the script entirely blowing up, as it does with the first line:

foo;  // ReferenceError: foo is not defined

We’re not particularly doing anything useful with foo here, but notice that the script fails out anyway. At this point any code that follows will not be executed. Your first instinct might be “Oh! I know how to contain these errors! We’ll use a try-catch!”:

try {
} catch(e) {
  e.message;  // "foo is not defined"

The script still fails, but not critically, so your script continues to execute. But this turns out to aversely affect performance. The basic lesson here is that try-catch can be useful in some situations, but shouldn’t be used where alternatives are available.

typeof foo

JavaScript has quite a useful remedy for this:

typeof foo; // "undefined"

Unlike everything else in JavaScript, typeof will deal with whatever you throw at it, including undefined variables. So you can use it as a simple check before using a variable that might not exist:

if(typeof foo !== "undefined") {
  // do something with foo

Note that this is easy to confuse with the undefined keyword, which in this case doesn’t help us one bit, as it gives us a fatal error:

if(foo !== undefined) {  // ReferenceError: foo is not defined


This filters out our first two cases, since they both evaluate to “undefined”:

typeof foo; // "undefined"

var bar;
typeof bar; // "undefined"

But this turns out not to work well for our other conditions, which evaluate differently:

typeof null;  // "object" (what?!)
typeof "";    // "string"

So we need to add other “if” conditions to check.. but there turns out to be a better way!

Exploiting loose typing

JavaScript is a loosely typed language, which means that it will “automagically” cast variables into other types when necessary (i.e. when adding a Number to a String), sometimes resulting in the unexpected. For instance, whenever we use the “if” statement, the expected input is a Boolean true/false value. If JavaScript gets anything other than a Boolean, such as a String or a Number, instead of blowing up completely (as in strictly typed languages such as C), it’ll cast the variable into a Boolean for you.

“How handy!” you might think. Except in the following unexpected cases:

if("0") {
  // this will run because "0" is true

if("false") {
  // this will run because "false" is true

To see what JavaScript will cast a value to without having to use an if statement, we could create a new Boolean value with the following:

Boolean(0);    // false
Boolean("0");  // true

Or we can use the less intuitive but quick way of using double exclamation marks (this will probably award you cleverness points in someone’s book.. hopefully those points actually matter):

!!0;    // false
!!"0";  // true

This works because !foo converts foo to a Boolean but negates its original value, turning it on its head. !!foo converts foo to a Boolean and flips it back to its expected value, which is the same value that’s evaluated by our if statement.

Using this ALMOST gives us the answer we’re looking for:

!!foo0; // ReferenceError: foo0 is not defined

var foo1;
!!foo1; // false

var foo2 = null;
!!foo2; // false (same as !!null)

var foo3 = "";
!!foo3; // false (same as !!"")

var foo4 = "bar";
!!foot4; // true (same as !!"bar")

Excluding the first example, now we can test for uninitialized variables (foo1), null variables (foo2), and empty strings (foo3) all with just an if statement:

if(foo1) {
  // do something with foo1

if(foo2) {
  // do something with foo2

if(foo3) {
  // do something with foo3

Dang… so close! But we can’t yet test the first case without an error:

if(foo0) {  // ReferenceError: foo0 is not defined


foo versus and

The secret to our solution lies in how JavaScript handles undefined variables versus undefined properties. Here’s a quick reminder on the difference between the two:

// variable foo
var foo;

// property bar (and object variable foo)
var foo = {};  // create an empty object to add bar too = "";

The difference between these makes all the difference whether a fatal error occurs:

foo;  // ReferenceError: foo is not defined

var foo = {};;  // undefined
foo.blah; // undefined

We can randomly invent and check any property of foo we want, and the code will keep chugging along:

var foo = {};
foo.something = "hello";

if( { // undefined, interpreted as false (same as !!
  // never runs

if(foo.something) {
  foo.something;  // "hello"

Now comes the magic. If you know anything about JavaScript running in the browser, you know that all global variables are part of the window object. This means foo and are equivalent:

var foo;

foo ===;  // true

// "this" is another bag of worms, but note this anyway ===;

So technically our variable foo is a property of the window object. So we should be able to check for any arbitrary variable in the window scope now!;  // undefined (not a fatal error!)

// even though we're checking for the same thing, we get a fatal error…
foo;  // ReferenceError: foo is not defined

Practical uses

Now as long as we have a global entry point for our code, we can write our code in such a way that it won’t ever give us a fatal error if our variables aren’t yet defined:

if( && {;

Of course nothing happens, because we haven’t defined foo. But why doesn’t give us a fatal error? Because the first test, failed out. It would be useless processing for the JavaScript engine to also evaluate the second statement, because the end result will still be the same (false && true results in false, false && false results in false). So it doesn’t get so far as

And now the code will work properly when we hook up our code to our foo global namespace:

var foo = {
  bar: function() {
    alert("hello world");

if( && {;  // "hello world"


It’s becoming common to see an abbreviation for the above code. Check out the following two methods, which accomplish the same thing:

// Method 1
if( && {;  // "hello world"

// Method 2 && && (;

Don’t get too scared.. these blocks of code are equivalent. Method 2 is shorter, but it simply goes something like this: if isn’t set, stop evaluating this line (just as above in the if statement). Otherwise, if exists then execute the code in parentheses, which gives us an alert (“hello world”);

Just a word of caution about using Method 2: it’s obviously less clear what’s going on here. Your own cleverness might actually result in unnecessary confusion, especially of other people work in the same code base and they’re at different levels of understanding. In these cases we should first strive to be clear, and then only clever if it’s not at the expense of being clear.

It’s also likely that a code minifier would take care of this cleverness for us at build time, giving us the best of both worlds.

Translate this page to English Translate this page to French Translate this page to Vietnamese

Recent articles
The Possible Working Methods of Python Ideology
JavaScript Research Paper: 6 Writing Tips to Craft a Masterpiece
Learning How to Make Use of New Marketing Trends
5 Important Elements of an E-commerce Website
How To Create A Successful Prototype For Your PCB
WordPress Landing Page Conversion Essentials to Convert More
4 Development Hacks To Make Your Website Launch A Success
Why Data Recovery Software and Services are Important
Why Engineers Specializing in DevOps Are the Wave of the Future
The Ultimate Checklist for HTTP to HTTPS Migration

Top view articles
65 Free JavaScript Photo Gallery Solutions
Top 10 Beautiful Christmas Countdown Timers
Best Free Linux Web Programming Editors
Top 50 Most Addictive and Popular Facebook mini games
Top 10 Free Web Chat box Plug-ins and Add-ons
50+ Beautiful Resources of HTML Form using CSS and JavaScript
Top 10 Best JavaScript eBooks that Beginners should Learn
The Ultimate JavaScript Tutorial in Web Design
HTML5 Web Workers Multithreading in JavaScript
Learn more about JavaScript Inheritance with Tiny JavaScript Example Codes

Free JavaScript Tutorials & Articles