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)
I would be nice if Fiddler could decrypt zstandard compressed requests.
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.
For now fiddler just have filter, and it not ignore traffic. Filter just hiding it.
Also Fiddler have option "Capture/Dont capture traffic" via menu File or F12. but it general for all. Also this option NOT work while the target app still use fiddler proxy.
My example problem :
I am using Nox to test MyDownloader app, while apk connect internet or requesting web data its ok to proxified by fiddler. But when I start downloading, the file is downloaded first to Fiddler cache until complete. after complete then fiddler continue request with that file response. That the problem. This also applied to all request in my PC. No problem if size just 20MB. But above 100M, 500MB, 1GB, sometime it make fiddler hang.
Also when i download file, then cancel it, fiddler still download file until complete. So to cancel that in fiddler, i need to disconnect it first.
For now, to bypass my problem i also using Proxi*fi*er filter to selecting mimetype.
Hello! The problem is described on this link: stackoverflow
Please add in Filter - feature block named "Request Body" with options "Show only if request body contains", "Hide only if request body contains"
Hi there, what's the correct way to call: JSON.stringify({}); JSON.parse("{}"); after calling these JSON methods, fiddler says: Variable 'JSON' has not been declared cheers, David
Could you add 'search text' function to the websocket tab?
In the File > Export > Export Raw Files code, there's a "Skip non-HTTP/200 responses" option. This option is designed for dumping files (either media files or files to be replayed by the AutoResponder) to a folder. For various reasons, clients and servers often will use Range requests for media downloads, meaning that the response code for a response might be HTTP/206 instead of HTTP/200, even if the full body is present. To enhance the file exporter, the code should look at the Content-Range response header for a HTTP/206 response. If the header is of the format: Content-Range: bytes 0-N/N+1 Then Fiddler should treat the response as a HTTP/200 and save the body to disk.