I would be nice if Fiddler could decrypt zstandard compressed requests.
Microsoft appears to have moved their web developer documentation from MSDN to MDN, making searches from Fiddler's toolbar return useless results. Please consider making the Search Cue text and Search URL configurable via a preference and set the defaults to "Search MDN" with a URL of https://developer.mozilla.org/en-US/search?q=$SEARCHTERMHERE&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=canvas&topic=svg&topic=webgl&topic=mobile&topic=webdev&topic=http&topic=webext&topic=standards
Problem: Today you have to leave the application and discover Fiddler listening IPs using ipconfig or "netstat -na | findstr 8888". Having the IP address list that the tool is listening will allow a fiddler user to not leave the application to discover all the IP addresses that the tool is waiting connections. Specially useful when you need to configure the proxy settings on and Android or IOS device and need to know what IP address to point the HTTPS proxy. I'd expect to see all the bindings somewhere on the bottom toolbar. A nice addition would be also the URLs to Fiddler Echo service to be shared with users that need to install the root certificate on devices and use Fiddler as a proxy for troubleshooting.
Since more and more websites enforce you to use tls 1.2 (and don't support tls 1.0 any more), I suggest that the list of protocols is automatically extended with tls1.2 by a next fiddler update - or at least there should be a single-time question box with Yes-No-Cancel to extend it.
Also see reference at https://www.telerik.com/forums/some-https-sites-are-unaccessible-when-using-fiddler
Hi everyone,
As a long-time user of Fiddler Classic, I’m writing to share an idea that could benefit both the community and the product's future. While Fiddler Everywhere is great and clearly the focus moving forward, there’s still a strong group of developers who prefer the speed, simplicity, and scripting power of Classic.
Let’s be honest — Fiddler Classic isn’t just “a bit outdated.”
In recent documentation and forums, the message is clear:
“We recommend switching to Fiddler Everywhere for the latest protocol support.”
This effectively signals the end of active support for Classic. While that’s understandable from a product strategy point of view, it leaves a large number of users in a tough spot:
Classic is still powerful and widely used, especially in Windows environments.
But it lacks support for modern protocols like HTTP/2, TLS 1.3, QUIC, gRPC, Brotli, ZSTD, etc.
Some users don’t want or need to move to a completely different interface — they just want Classic to stay viable.
Here’s what I propose:
Introduce an optional premium subscription tier for Fiddler Classic, shared with Fiddler Everywhere.
This would allow users to continue using Classic, while unlocking new features such as:
✅ HTTP/2, HTTP/3, and gRPC decoding
✅ TLS 1.3 and QUIC inspection
✅ ZSTD and Brotli decompression
✅ Modern cipher suite analysis
✅ Optional UI improvements like dark mode
And best of all:
If you're already a Fiddler Everywhere subscriber, you automatically get access to these premium features in Fiddler Classic — no double payment, no separate license.
For Users:
No forced migration — choose the tool that fits your workflow.
Lightweight, scriptable Classic experience stays alive.
One subscription, full flexibility.
For Progress (Telerik):
Generates sustainable revenue to support modern protocol implementation.
Maintains goodwill with loyal Classic users.
Provides a “bridge” to Fiddler Everywhere for hesitant adopters.
Keeps Classic usable without splitting the product line.
Both Fiddler Classic and Fiddler Everywhere are built on the .NET stack.
Protocol decoding, TLS inspection, and compression logic can be modularized or shared.
A unified Telerik licensing system already exists — it can govern access to both products.
Would you support a shared subscription model like this?
Let’s not let Fiddler Classic fade away simply because it’s "not the focus" anymore. With a shared subscription model, both tools can thrive — and users can decide what works best for them.
If this idea resonates with enough of us, maybe we can bring it to the attention of the Fiddler team and show that there’s a real demand for keeping Classic alive — the modern way.
Thanks for reading!
The .NET Framework has added support for TLS/1.3.
We should do the work to enable TLS/1.3 in Fiddler (it's very little additional work to add "Tls1.3" to the options dialog and the underlying code).
Fiddler's Cookies inspector doesn't do very much today other than breaking out the Cookie header into a word-wrappable format.
It would be nice if it (and even the Headers inspector) flagged cookies that were sent expired (with an Expires header before the value of the Date header on the server's response). Otherwise it's hard to notice that a cookie being "Set" is actually being "Deleted".
First of all I'll say that I've investigated it deeply. I used to have fiddler 4 , earlier versions and never updated. When my computer turned to sleep , I was able to wake it by trying to rdp it. The connection itself to rdp - woke the computer ( via network card) and the computer awoke ,and then I could connect to it. this feature is called "wake on link". After installing fiddler ( latest version) , suddenly my computer won't wake up from sleep when trying to connect to pc. at first I didn't know what whet wrong and then I started uninstalling latest installed programs When I uninstalled fiddler , it started waking the computer So I don't know what's you've done in the last version , but it f*s some other functionalities. please fix it.
I'm working on an open-source Fiddler Classic extension to search the Session log (history). I'm not aware of such an extension and the lack of a search feature for the log entries always bothered me.
My current implementation already works, it searches the history listview, but it can only search in the text displayed in the listview itself because additional data is only available in the HistoryItem instances, attached to the Tag property of each list item.
Since HistoryItem is internal, I cannot access this class. I could work around this by using reflection but the internal classes of Fiddler are all obfuscated so, at the very least, my source code would look very strange and unmaintainable.
Please make HistoryItem public so it'd be accessible and un-obfuscated.
The error messages pops up on Windows 10 version 1703. Fiddler installs and runs with not issues on Windows 10 version 1607.
I often have to locally save a lot of responses manually.
My workflow is:
• Open a .saz file
• Search for a particular request
• Save the response locally.
For that, I always have to manually click the "Response body is encoded. Click to decode." Button.
Fiddler Classic doesn't have a feature to automatically decode the selected request's response body.
So if I don't pay attention, and skip a step, I will store an encoded response body, without ever noticing it. Which can cause trouble later, since these files are then sent to my customer. And the customer could randomly check the files.
I need a toggle in Fiddler, that automatically decodes the selected request's response body.
Today, Fiddler exposes these two events to handle scenarios where the user is saving or loading a SAZ file.
/// fires just before a SAZ file is saved
public static event EventHandler<WriteSAZEventArgs> OnSaveSAZ;
/// fires just after a SAZ file is loaded
public static event EventHandler<ReadSAZEventArgs> OnLoadSAZ;
Equivalent event handlers should be created for the scenario where a user is Importing content into the Sessions list (e.g. using NetLog import or HAR import, etc). Otherwise, developers must undertake cumbersome workarounds to detect that a list of Sessions has been created/loaded from a file import, if, say, they wish to perform processing on those imported Sessions (adding custom properties or changing the display properties in the Session list).
Would really appreciate a proper machine based installation again, user-based installs are difficult to manage in corporate/enterprise environments & the psuedo machine install of redirecting install folder & creating new shortcuts isn't great, especially if as you mention yourself extensions wont work.
I understand the advantage of not needing admin rights to install programs, but surely most of the targeted audience for this application would either A) have admin rights, or B) be in a managed environment with deployment software in use (and potentially white-listing/App Control software preventing unauthorized apps to run anyway)
This would be useful to compare a completed working trace versus a non-working trace, side by side and see what the difference in the traces are.
I've attached the raw HTTP response, copied directly from Fiddler. At lOperations[0].lRecords, you'll see that there are 2 records (arrays) and that each record contains 6 items, the last of which is an array. However, when I view the resonse using the JSON filter, the second of these arrays appears to contain only 5 items. I'm sure that the bug has something to do with the fact that the sub-array in the second array is an empty array, but it should display as an empty array, not as if it weren't there at all.
I have a base64 of a gzip of utf8 bytes of a string - base64(gzip(utg8(string)))
Please add to the TextWizard options in the transform to encode/decode a string to gzip
When there's a HAR file with h3 entries, they are either misinterpreted or ignored.
I know how to fix it both in the importer/exporter DLL and in Fiddler.exe.
I can submit a correction.