How I debug JavaScript issues

This post is more than 2 years old.

After helping a friend earlier this week with a JavaScript issue, I thought I'd quickly write up the normal ways I attack issues with JavaScript. This is not meant to be a definitive guide per se, but just how I go about dealing with problems. I'll be talking about Chrome, but pretty much everything mentioned below is doable in other browsers (some even in IE).

Check for Errors in the Console

First and foremost, I check the console. Normally errors are not shown to users. Consider the follow example:

<script> var x = 1; var y = 2; var z = x+y2; </script>

If I open this up in my browser, I'll see nothing wrong. Obviously if the page tried to display Z I'd see nothing or something unexpected. But there isn't a large error alert, flashing lights, or klaxons. But as soon as I open the console I see:

You can even click the line and see the context - which would be real useful in a large file.

What isn't obvious in this screen shot is that Chrome will also highlight the line. Not sure why they fade it out after a few seconds, but it does make it even more obvious.

Check for Errors in the Network Panel

The other big one is the network panel. This shows all network activity and is useful in two ways. One error I see all the time (and this was the error my friend had), was simply not noticing that a library didn't load. This could be because of a web server permission issue or simply forgetting to upload a file! Consider:

<script src=""></script> <script> $(document).ready(function() { console.log("moo"); }); </script>

Notice the bad URL for the jQuery load? In the Network tab, this shows up right away (note, it also creates an error in the console since I tried to use it, but if I was not using jQuery right away, this wouldn't be obvious):

Notice that the Network panel let's you filter. That's recommended if you have a lot of stuff going on, but, you probably want to check everything first. For example, you may be using jQuery UI. If you forget to upload the CSS, things will definitely be wonky, but that wouldn't show up as a missing JavaScript library.

The other big thing to look for here is in the XHR requests area. XHR requests represent your Ajax requests. A full look into this is a bit much for this blog entry, but basically, if you are making an Ajax request for data, you want to check your network request to see what the server returned. Did the server throw an error? Did it return data in a way you didn't expect? Did your result include formatting? For example, many people will wrap all their requests in a template. While this works great for the rest of the site, including a template around your JSON data will break any code that tries to parse it. Don't forget to look at the complete response. You may have whitespace after your JSON that is a bit off screen. You can also right click on an XHR request and open it in a new window to make it clearer.

Finally - one more thing you want to pay attention to is size. If your application is working, but working slowly, look at how big those XHR requests are. Ajax isn't magic. If you return 100K of JSON data it's still going to take time for that data to transfer to the client.

Event Handlers/Selector

This is mainly jQuery based, but could apply anywhere. Another thing I check is my event handlers and jQuery selectors. For example, consider:

$("#mything").on("click", function() { });

If I notice that my click handler isn't running, I check to ensure that #mything is actually matching something in the DOM. In my startup routine I may do something like so:


If I see that jQuery couldn't find it, then I look into my DOM and see what's up. It could be as simple as a typo.

The Debugger

And finally, if all all fails, I try out the debugger. Again, this is a bit too much to cover in detail in this blog post, and, I'm very new to this myself, but the debugger let's you set breakpoints and step through your code. If that doesn't quite make sense to you, consider this - you can pause your JavaScript application and freeze it in time. You can look at variables and their state. You can then have your application proceed one line at a time. It's like God Mode for the browser.


<script> var total=0; for (var i = 0; i < 10; i++) { total+=i; } </script>

in Chrome, I added a breakpoint on total+=i, and then added a watch expression (i.e., 'watch this variable') for total. I stepped through the loop a few times and was able to watch the variable increase:

So... that's it - for me anyway. What tips do you guys have?

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by PaulH posted on 12/30/2011 at 10:15 PM

this isn't making me like javascript any better you know...

Comment 2 by Raymond Camden posted on 12/30/2011 at 10:18 PM

You're kidding, right? I know I must be misreading you. Every platform has debugging tools and techniques.

Comment 3 by PaulH posted on 12/30/2011 at 10:45 PM

nope, only 1/2 kidding. the current tooling for JS simply blows. i mean geez louise, you're using a browser to debug & you're *not* complaining.

i hope adobe has something up their sleeve for JS development, right now i despair. it just feels like we're going backwards.

Comment 4 by Raymond Camden posted on 12/30/2011 at 10:47 PM

Since JS executes in the browser, I don't see using the browser to debug as an issue. To me it just makes sense.

I'm not saying tooling can't improve. I'm looking at IDEs now and trying to find the best one for me.

Comment 5 by Jon Cavanaugh posted on 12/30/2011 at 11:08 PM

Rock on.. great description of how to systematically troubleshoot JS issues. This will be passed around my office. Thanks Ray!

Comment 6 by rip wit posted on 12/30/2011 at 11:26 PM

Personally, I'm amazed at how good the debuggers are for Javascript in the browsers. Chrome's Developer Tools are great with the Mozilla Firebug plug-in right behind. IE Developer Tools lack a bit, but what-the-hey.

Usually I'll look at most of our web offerings in 2-3 browsers and use the (native) debugger. If it is going to involve a lot of browser-to-debugger switching, Chrome is the best mainly because of the speed. Also, a dual-monitor setup is really necessary; but that's true for any real-time debugging.

Thanks Ray, and let's all have a great new year!

Comment 7 by Chuck S posted on 12/30/2011 at 11:44 PM

Visual Studio has gotten better with JS debugging, it allows you to set break points and step through. I know this isn't a VS blog but it's an option for VS developers.

Comment 8 by Raymond Camden posted on 12/30/2011 at 11:45 PM

Chuck, it's funny you mention that. I've heard from more than one person that Visual Studio has gotten -real- good for HTML/JS. It's on my list of things to try in 2012 (also so I can try Windows Phone).

Right now my IDEs are:

Webstorm (need to buy a license)

Comment 9 by Brian Swartzfager posted on 12/31/2011 at 12:37 AM

The other day someone on Twitter mentioned the jQuery-inlog plugin, which when active automatically documents DOM actions and values within the console:

Haven't had a chance to play with it yet, but the examples on the page look quite promising.

Comment 10 by pomeh posted on 12/31/2011 at 3:18 AM

Nice article :)

We can talk about the "debugger" keyword, that lets us create breakpoints right in the source code. This is very useful in some cases:
- when you have a lot of big files and you don't want to search for the line in the script panel,
- when you have a system of build of your scripts, here the source & generated code are different, and matching one with another could be hard,
- when you have a dynamically generated portion of Javascript (this is really really bad but I've already encountered it...)

Have you seen the videos from Paul Irish talking about using the console ? Here is the link I've learn a lot from it :)

Also, sometimes, knowing the differences and evolution of the differents consoles (Firebug, Chrome Dev, Opera Dragonfly) saves time :)
For example, in Chrome you can activate a breakpoint when the user is doing an "mouse event", without knowing the relevant code, awesome :) This is shown in the videos I think. Also, Chrome lets you edit the code right in the browser ! Time saver :)

A last general tip, sometimes it's cool to create/edit/debug some code right from the console. I mean, you get a code portion you want to modify, you run it from the console, you see directly the result, and make modifications until you're satisfied :) Time saver too ;)

Hope this'll help :)


Comment 11 by Raymond Camden posted on 12/31/2011 at 3:42 AM

Slick, didn't realize there were Console commands for the debugger. I think I'd probably prefer the visual UI, but the CLI looks powerful:

Comment 12 by Bob Chesley posted on 12/31/2011 at 10:59 PM

I have also come to love the debugging tools in Chrome. Here's another link to some excellent video tutorials from Paul Irish that I found particularly useful - <a href="http://updates.html5rocks.c...">Chrome Tips</a>.

Comment 13 by Phillip Senn posted on 1/3/2012 at 12:15 AM

Thanks Ray (and others!).
Looking at the Net tab allowed me to tighten up a few things.
I had been loading jQuery with Google's jsapi followed by google.load, but the Net tab showed me that loading the script directly from meant it would load chronologically.

Comment 14 by James Moberg posted on 1/4/2012 at 3:21 AM

Whenever I'm debugging a javascript issue, I always start with the HTML now. Does it validate? Does it have a DOCTYPE? Are there any duplicate IDs? Improper tag nesting? These are critical issues that Firebug won't quickly reveal.

Initially a hotel client had complained that the fonts used on their reservation page weren't correct. We discovered that the javascript font replacement library we were using wasn't working in IE9 because the webpage was in "quirks mode" because it lacked a valid DOCTYPE. To make matters worse, there wasn't any way for us to add a DOCTYPE (closed source) and the application was no longer being supported.

For validation using Firefox, I recommend "HTML Validator". It uses Tidy and OpenSP to validate locally on your machine without sending HTML to a third party server.