Essential Tools for Debugging Web Applications

Written by Jordan H.

cover image

Impress your coworkers or boss with your debugging skills!

Finding what’s wrong with desktop or mobile applications is (for the most part) a breeze. But full stack is an entirely different beast. Each part has a different protocol and structure. In this article I list some simple tools that can help you debug your application.

In order for these tools to best server you it helps to provide a minimal , reduced input sample.

For example, if you are trying to see why a list of users doesn’t display, take out the code that displays the users and select only three users. If you can get that little example to work, put the code back in the main application.

I’ve found it’s also helpful to start on the front-end and work my way back. So that’s what I’ve done in this article, too. Let’s start off with some cool front-end tools.

For the Front End

Web Console

Web JavaScript Console

There’s nothing fancy to it.

You’ll be spending a lot of time checking out the console messages. If any front-end JavaScript throws an error it’ll show up here in a beautiful brilliant red.

If there’s a templating issue, the Inspector can show you what’s up.

If everything looks golden, it can be helpful to check out the Network tab. Sometimes a request can be erroring out. Pay careful attention to the status code (rule of thumb: status codes of 200‘s - 300‘s = good, 400‘s and beyond = bad). The URL and path are also important.

If this is the case, you can right click on the request to copy it and use an API Tester to massage the request until you get a result you expect.

You can also copy javascript objects and inspect them in the console. This way you can verify the object looks correct.


It can be time-consuming to test your application by pointing, clicking and typing. Carpel tunnel syndrome is no laughing matter. That’s why I highly recommend immediately using selenium when you’re developing the frontend.

Selenium is essentially a web browser and takes the actions that a user would take. This is great because you can define what you expect your website to look like based on a workflow. Just hit run, go for the extra cup of coffee, then come back and see the results.

You can find out more about selenium here.

The Shell

I’m not talking about PowerShell or BASH here (though those could be used). For simple “why isn’t this working?” scenarios I like to drop into a node shell to experiment.

Perhaps you used the node shell early in your development career but have since abandoned it. Why not give it a try whenever you get stuck?

For the HTTP Layer

API Testers



cURL is the command line option.

Your mother probably used this one. It’s the tried and true method of testing API calls. It’s the most basic one so there are no fancy bells or whistles like saving queries.

So sorry, no themeing either.

You may have used it for simply fetching some text (a GET request), but you can also use it to test any request, really (POST, DELETE, PATCH).

If you’re on Linux or Mac you already have this installed. If you’re on Windows you’ll need a Mingw shell and install it from there.



I was first introduced to Postman when I attended an OpenAPI conference. A bunch of young hyped up sales people in bright telltale orange t-shirts handing out cool swag turned me on to the idea of an API tester application.

Initially it can be pretty daunting to use, but play around with it for 5 minutes and you’ll get the hang of it.

You can install it here.



For the open source fans among us, there is Insomnia, which is pretty close to Postman with a more liberal license.

One feature I like is the “Paste as cURL” feature. Basically, if a web request isn’t working in Firefox. I use this all the time for any GraphQL queries that don’t quite make it.

You can install it here.


Finally, there’s the backend.

Unfortunately there aren’t a lot of neat-o tools here to help you out. I guess because backend developers usually get their tasks, close the door to their cave and don’t come out until the year 2027. However, there are a few programs that might help.

How do you know if an issue is present on the back-end?

Well, ideally you’d know immediately with unit testing.

However, there are times when you thought you covered 100% of the cases and something returns null unexpectedly. Or you might inherit a bit of code that did NOT include unit tests.

So, what are some telltale signs that the issue is in the back-end?

  1. You’re receiving missing values. JavaScript will complain about this.
  2. You’re receiving strange values (for example, object {...4 when you expect true). JavaScript will also complain about this.

I’m sure there are others, but most of the cases have these 2 symptoms.

In addition there are 2 common areas where back-end issues crop up:

  1. The data in the database is incorrect.
  2. There’s an exception in the backend framework.

Let’s first take a look at some database tools.

Database Tools

pgadmin4 for PostgreSQL


Be careful, because if you try to install pgadmin from a repository you’ll probably end up with a very outdated version.

Make sure to read the docs for your system to make sure you’re downloading the proper verison.

I’ll admit the interface is a bit awkward to use. And it can take a while for the database tables to come up.

But it’s an easy way run queries and see if the structure is what you expect.

You can find it here.

Robo3T for Mongo


The mongo shell is all fine and dandy, but sometimes you want the fancy syntax highlighting and the ability to go to a specific character.

I found Robo3T to be pretty decent. They do get a little annoying with “hey, try these extra features!” but I understand the need to earn a profit.

You can find it here.

For everything else there’s MySQL Workbench, SQLyog, DataGrip…

There are too many to list here, but countless articles have been written about other database GUI applications that can aide in debugging full stack applications. Feel free to do your own research.

I do have experience with MySQL workbench as a catch-all GUI. My take is that it’s…decent…if you absolutely have to use it. I usually shy away from the Eclipse-based applications: they tend to be very feature-rich with inadequate basic functionality. Like a cake made mostly of frosting.

Framework Tools

The Shell

I’d really just look into the shell for this one. I say “the shell” because while the front-end is most likely node, the backend can be node, Python (my favorite), Java, Ruby, or something else.

If your minimal example is way to long to fit into the console I’d suggest setting up a very minimal project and just experimenting. For example, rendering a microservice response might not be working. I usually remove all of the fluff and reduce the problem to just the response not rendering. This is where some of the other tools mentioned above might come in handy.

(…and also…)

Another tool that I should throw in there is ngrok. I didn’t place it in a category because it’s useful in a variety of different scenarios.

ngrok is a tunnel that allows a web app to be available from anywhere. This is useful for anything from testing endpoints to showing a colleague something cool.

It can be downloaded here.

Now, go forth!

So now the next time you feel stuck on a problem, you’ll have the tools and the know how to get un-stuck.

And, believe me: I also feel sweaty-palmed and overwhelmed when I see that large stack of syntax errors. So you’re not alone in trying to tackle the mountain. But over the years I’ve found these tools are indespensible and I hope you find them helpful as well.

Did you like this article?

Did you know I'm available for hire?

Send me an email here:

Or connect with me in Wire: @nswered