How to Inspect and Diagnose Web Errors with Fiddler2

How to Inspect and Diagnose Web Errors with Fiddler2

Fiddler2 is a tool that acts like a special proxy server between your computer and a website.  It is probably the most popular debugging proxy out there.  It basically works by your web browser sending HTTP or HTTPS requests to Fiddler which then forwards them to the web server.  Fiddler also captures all of the web server’s responses.   It then allows you to dissect all of the information that is passed back and forth.  This can be extremely useful when developing or trying to troubleshoot bugs where you are not sure what is being passed back and forth.


Getting Started

Go to and click on the ‘Free Download’ button.  We chose the ‘Fiddler of .Net4’ option.  Walk through the setup process, it is very straightforward, then launch the application.  You should initially see a screen like this.


At first glance, this can be a lot to take in, but we will go through some of the basics.  On the left hand side, we have the Web Session List, which displays information about each request from your web browser. 

Let’s look at a few of the columns in the Web Session List.

# - These icons represent the type of file being accessed.
Result – This is the status code of the HTTP request for the web call.  For instance:
           200 – Success
           404 – Requested item not found
           401 – You do not have authority to the requested item
Protocol – HTTP, HTTPS, FTP
Host – The hostname of the server that is being requested.


On the right hand side, we have tabs that display specific information about the selected item from the Web Session List.  We will get to some of the details next.  Let’s open up a web browser and go to the following web address:


If you look at the line, where the red arrow is pointing, you will notice that the Host is the same as the URL you typed in.  This is the initial call to the web server.  If you look below it, you will see separate calls for different items like pictures and fonts.  These separate calls happen behind the scenes and you would never know they were occurring if not for Fiddler.  Now click on the line for the initial call and you should see the right-hand panel change.


Next, we want to click on the Inspector tab, then click on the ‘Download and Install SyntaxView’.  This add-on is valuable for web developers because it offers syntax-highlighting for most major web formats like HTML, JavaScript and CSS.  You can go to, , for additional add-ons provided by the Telerik team.

After you have installed the add-on, close Fiddler, open it back up and refresh your web browser.   Next, click on the initial call to


On the right hand side, we start off with the Inspector tab already selected.  You can see the Request Header on the top; and at the bottom you can see additional data about the Response.   Here is some additional information about some of the other tabs.

Inspectors:  Allows you to see the details of the HTTP request and response.  Within this tab, there are a lot of sub-tabs. 
                TextView: Shows the body of the response in plain text.
                Raw: Show the entire response.
                XML: Shows a collapsible XML browser view.
Statistics:  Includes information like bytes sent and received and a breakdown of how big the header versus the body.  It also includes rough estimates of download times from around the world.
Filters:  Allows you to filter what you see in the Session List.   You can filter by a lot of different criteria, for example, host, process id, or if the traffic is coming from the internet or intranet.


Here is a brief example of how Fiddler can be helpful.  The first picture shows the initial call to the website.  You can see the all of the subsequent calls that include getting pictures, fonts, JavaScript files, etc.  Next, we will clear the Web Session List in Fiddler. Look for the red arrow in the screenshot titled “Remove all Session items” to see where the “Remove all” button is located.  By clearing the session information, it will allow us to see what is generated when we make a subsequent call to the web server.  Finally, we refresh the web browser and look at the Web Session List.  This list is a lot smaller because your browser has cached a lot of the information that was originally requested.   Information like this can be priceless when trying to figure out what is being passed back and forth between a user’s browser and a website.

Initial Call


Remove all Session items




Last example, suppose we have an application that makes an AJAX call to a server.  In this instance, it sends information to the server to be saved.   Imagine you are working on a change to the application but cannot figure out why a specific value is not updating.   If you look at the picture below, we can see what a response to an AJAX call looks like.


You can see in the top section, we have the Inspector tab and the WebForms sub-tab selected.  This shows us the information that was sent to the server from the web browser.  Below that, in the response, we see the data that the web server sent back to the client.  Here we can see exactly what is being passed up and down the pipeline and it can help us pinpoint where problems are occurring.

© 2020 IT Solutions Consulting, Inc.. All rights reserved. Privacy Statement  |  Site Map