Fiddler in 2025

The Fiddler Web Debugger is now old enough to drink, but I still use it pretty much every day. Fiddler hasn’t aged entirely gracefully as platforms and standards have changed over the decades, but the tool is extensible enough that some of the shortcomings can be fixed by extensions and configuration changes.

Last year, I looked back at a few of the mistakes and wins I had in developing Fiddler, and in this post, I explore how I’ve configured Fiddler to maximize my productivity today.

Powerup with FiddlerScript & Extensions

Add a SingleBrowserMode button to Fiddler’s toolbar

By default, Fiddler registers itself as the system proxy and almost all applications on the system will immediately begin sending their traffic through Fiddler. While this can be useful, it often results in a huge amount of uninteresting “noise”, particularly for web developers hoping to see only browser traffic. Fiddler’s rich filtering system can hide traffic based on myriad criteria, but for performance and robustness reasons, it’s best not to have unwanted traffic going through Fiddler at all.

The easiest way to achieve that is to simply not register as the system proxy and instead just launch a single browser instance whose proxy settings are configured to point at Fiddler’s endpoint.

Adding a button to Fiddler’s toolbar to achieve this requires only a simple block of FiddlerScript:

	// Rules > Customize Rules, place this just inside the HANDLERS class…

	// Add a button to Fiddler's UI for "Single Browser Mode", where only one browser window will
	// send its traffic to Fiddler.
	public static BindUIButton("SingleBrowserMode \uD83D\uDC40")
	function LaunchSingleInstance() {
	// Tell the system we're not the proxy anymore
	FiddlerApplication.UI.actDetachProxy();
	// Launch a single browser instance pointed directly at Fiddler.
	System.Diagnostics.Process.Start('msedge.exe',
	'–user-data-dir="%temp%\\throwaway" –no-first-run –proxy-server=127.0.0.1:' + CONFIG.ListenPort.ToString() + " about:blank");
	}

view raw Single.js hosted with ❤ by GitHub

This button is probably the single most-valuable change I made to my copy of Fiddler in years, and I’m honestly a bit sick that I never thought to include this decades ago.

Disable ZSTD

ZStandard is a very fast lossless compression algorithm that has seen increasing adoption over the last few years, joining deflate/gzip and brotli. Unfortunately, Telerik has not added support for Zstd compression to Fiddler Classic. While it would be possible to plumb support in via an extension, the simpler approach is to simply change outbound requests so that they don’t ask for this format from web servers.

Doing so is simple: just rewrite the Accept-Encoding request header:

	// Add just inside here:
	// static function OnBeforeRequest(oSession: Session) {

	// Don't request zstd content-encoding because Telerik didn't bother adding support.
	if (oSession.RequestHeaders.ExistsAndContains("Accept-Encoding", "zstd")) {
	oSession.RequestHeaders["Accept-Encoding"] = oSession.RequestHeaders["Accept-Encoding"].Replace(", zstd", "");
	}

view raw no Zstd.js hosted with ❤ by GitHub

Integrate with VirusTotal

Since moving to the Microsoft Defender team, I spend a lot more time looking at malicious files. You can integrate Fiddler into VirusTotal to learn more about any of the binaries it captures.

	public static ContextAction("Show Hashes")
	function doHash(arrSess: Session[])
	{
	for (var i: int=0; i<arrSess.Length; i++)
	{
	FiddlerObject.alert(
	"_MD5_\n"+arrSess[i].GetResponseBodyHash("md5") + "\n\n" +
	"_SHA1_\n"+arrSess[i].GetResponseBodyHash("sha1") + "\n\n" +
	"_SHA256_\n"+arrSess[i].GetResponseBodyHash("sha256") + "\n"
	);
	}
	}


	ContextAction("VirusTotal")
	public static
	function doVTCheck(arrSess: Session[])
	{

	for (var i: int=0; i<arrSess.Length; i++)
	{
	var oS = arrSess[i];
	if (oS.bHasResponse)
	{
	Utilities.LaunchHyperlink(String.Format(
	"https://www.virustotal.com/en/file/{0}/analysis/",
	oS.GetResponseBodyHash("sha256").Replace("-","")));
	}
	}
	}

view raw HashSample.js hosted with ❤ by GitHub

Beyond looking at hashes, I also spend far more time looking at malicious sites and binaries, many of which embed malicious content in base64 encoding. Fiddler’s TextWizard (Ctrl+E) offers a convenient way to transform Base64’d text back to the original bytes, and the Web Session List’s context menu’s “Copy > Response DataURI” allows you to easily base64 encode any data.

Add the NetLog Importer

If your goal isn’t to modify traffic with Fiddler, it’s often best not to have Fiddler capture browser traffic at all. Instead, direct your Chromium-based browser to log its the traffic into a NetLog.json file which you can later import to Fiddler to analyze using the Fiddler NetLog Importer extension.

Learn about using Fiddler to analyze NetLogs.

…And More…

There are a zillion other useful little scripts you might add to Fiddler for your own needs. If you look through the last ten years of my GitHub Gists you might find some inspiration.

Adjust Settings

Configure modern TLS settings

Inside Tools > Fiddler Options > HTTPS, make it look like this:

Use Visual Studio Code as the Diff Tool

If you prefer VSCode to Windiff, type about:config in the QuickExec box below the Web Sessions list to open Fiddler’s Preferences editor.

Add/update the fiddler.config.path.differ entry to point to the file path to your VSCode instance.

Set the fiddler.differ.params value to --diff "{0}" "{1}"

Miscellaneous

On the road and don’t have access to Fiddler? You can quickly explore a Fiddler SAZ file using a trivial web-based tool.
Developers can use Fiddler’s frontend as the UI for their own bespoke tools and processes. For example, I didn’t want to build a whole tampering UI for the Native Messaging Meddler, so I instead use Fiddler as the front-end.
Malware-hunter Jérôme Segura has put together a package of Fiddler customizations designed for hunting for malicious web traffic.
More? Do you have any great suggestions for how you’ve tailored Fiddler to your modern workflows? Send me a comment!