Understanding Differences Between Web Debugging Proxies
Tags: fiddler, proxyman, charles, webdev
Published: 2020-08-27 19:49:27

Web debugging proxies like Fiddler are a little…shall we say…complicated. Even people with computer science backgrounds don’t necessarily know how they work. This sort of obscurity can create problems for people if they’re, say, tasked with determining which piece of software would suit their or their company’s needs best.
 
I’ll give you a quick rundown of the three most popular options in the field: utilitarian and focused **Charles**, bouncy up-and-comer **Proxyman**, and (of course) longtime favorite Fiddler, specifically the recently-released updated version **Fiddler Everywhere**. The goal here is to give an understanding of the points of comparison between different proxies, so you can draw your own conclusions about which one fits your needs. 

If you’re wondering what exactly a web debugging proxy is, I explain that [here](https://dev.to/backslash42/what-is-fiddler-everywhere-gip).


# Charles

Ask anyone who works in software if they’ve heard of a web debugging proxy, and if they have, chances are they’re thinking of either Fiddler or [Charles](https://www.charlesproxy.com/). While not quite as old as Fiddler, Charles is still widely used, and serves as a good starting example.

The best way to imagine a proxy like Charles is as a net your computer is casting into the flow of requests and responses heading in and out. Every time a session passes through, Charles will add it to its live traffic stream, showing you the URL for the webpage, the method the computer wants to use, the size of the session in bytes, etc. Clicking on a session in the stream will show you even more information, like when the request and response were sent and received, the HTTP headers that hold various metadata, and any code like JSON, HTML, or XML that’s being sent to or from the computer. This is why it’s called a debugging proxy; all the information it provides is useful for analyzing how a website—say, one that you’re currently building yourself—interacts with the rest of the Internet.

![Charles's user interface: no frills, no nonsense, no fun.](https://dev-to-uploads.s3.amazonaws.com/i/ixw2gzvwvhy9rkq6fc9p.PNG)

A toolbar at the top of the interface gives you even more options. You can throttle your Internet connection to simulate bad WiFi, or repeat a selected request without having to go and reload the website. Two of these actions are very important, however. One lets you compose your own requests by taking an existing one, manually editing it, and then resending it. For someone with a good knowledge of the structure of URLs, this can be a very effective tool for seeing how a website reacts to basically anything you can throw at it. The other option lets you create breakpoints: think of them as little sub-nets on either side of the main net that capture sessions before they even get to Charles, and let you decide whether to let the sessions through, redirect them, or block them entirely.

That’s a pretty good summary of the three things a web debugging proxy should be able to do: show you the inner workings of each session that passes through your computer, send custom requests, and edit server responses. Let’s see how Proxyman and Fiddler handle these tasks.


## Proxyman

Unlike Fiddler and Charles, [Proxyman](https://proxyman.io/) is brand-new; it was created by a small team in Singapore and released just this year for Mac. But this isn’t the only reason it’s a good contrast with Charles. Although Charles is cross-platform and undoubtedly effective, it is one of the least user-friendly apps I have seen. In addition to a rather bland and uninspired style for the documentation and UI, the 1-month free trial inserts artificial 5-second delays at random, and will *force-quit itself after 30 minutes*, meaning actually doing anything substantial with Charles requires shelling out $50. 

![C'mon, man, why you gotta do me like this?](https://dev-to-uploads.s3.amazonaws.com/i/8icjpjtd2su6dzbhmb61.PNG)

Proxyman, on the other hand, tries very hard to come off as bouncy and friendly as possible. Its website declares the program “Modern and Delightful,” and its UI provides just as much information as Charles with a lot more color. Being easy on the eyes is good for a computer program, and Proxyman manages to make even giant blocks of code fairly easy to parse quickly. In addition, its free version only limits the number of internal tabs you can have open, preventing you from multitasking but at least letting you use the darn thing.

![Proxyman's UI. Taken from the Proxyman documentation.](https://dev-to-uploads.s3.amazonaws.com/i/9mdhzi78zqufaaox4kzi.png)

Proxyman takes Charles’s ability to edit requests one step further by having a mechanism specifically for creating requests from scratch. The “Compose” tool, as it’s called, lets you make your own requests without having to use an existing one as a base. This gives you a lot more freedom as to what exactly you can send, as long as you know the format that the website’s API understands. (API stands for Application Programming Interface; it’s essentially a screen in front of a piece of software that lets it respond to requests from different pieces of software.) However, Proxyman has no equivalent to Charles’s breakpoints, essentially trading response editing for request editing. It’d be cool if there was a program that could do both equally well.

Oh, wait.


### Fiddler Everywhere

Having a separate tool for writing custom requests is a cool idea. So cool, in fact, that [Fiddler Everywhere](https://www.telerik.com/fiddler) has separate tools for writing custom requests and for editing responses. The Composer and Auto Responder tabs, when combined with the Live Traffic Stream, create a three-pronged approach that no other program in the business can match for versatility. You can add headers and parameters to the request with key-value pairs, letting Fiddler do the work of converting them into the proper format for an API call.

![The possibility/impossibility switch. Taken from the Fiddler Everywhere documentation.](https://dev-to-uploads.s3.amazonaws.com/i/7umk6aepmfimgcurziio.png)

The most mind-bending thing about Fiddler, however, is the Auto Responder, which lets you create a conditional ruleset for incoming responses. If a response meets the criteria you lay out, you can specify almost anything you can think of to happen to it automatically. There are so many ways you can fiddle (haha) with webpages; replacing the logo on Google’s homepage with a picture of your choice is only scratching the surface. 

And beyond that, Fiddler is just as user-friendly as Proxyman. The only things the free version restricts are the inbuilt collaboration features (oh yeah, you can share sessions, requests, and rules with anyone via email, did I mention that?) and the number of Auto Responder rules you can have active at once. Not only that, but its online documentation is crowdsourced, meaning that it can draw on the insane wealth of knowledge Fiddler’s huge user base has gathered in the 17 years of its existence. An easier explanation of how to use such complex software you will not find.

There are plenty of web debugging programs out there, and they’re all good at different things. But an important thing to note is that they all pick one or two things to focus on. Some are just requests composers. Some are just response editors. Charles and Proxyman have a fleshed out live traffic stream with some functionality in one of the other areas. But even if some of the other programs do one of those things really, really well, Fiddler is the only one that does all three. And it barely sacrifices any depth at all to get that breadth. Sure, if you know you only want to write API calls, it might not be the best choice; but for general applicability, nothing’s better.