I’ve shared the stories behind the Fiddler Web Debugger a fair bit over the years, in the Fiddler Book, in a talk at the CodeMash conference in 2015, and on this blog. It features prominently in my to-be-completed (some day?) memoir, and I’ve enjoyed telling Fiddler stories to folks who ask over the years. (I’ve also written a ton of content about using Fiddler.)
Over two decades, what was once a little side project came to influence a very meaningful percentage of my life, including where I live today and so many of my life’s experiences.
On Monday morning, I got a ping from someone from Progress Software, acquirers of Telerik in 2014, after Telerik acquired Fiddler (and for a few years, me) back in 2012. They asked for an email address to which they could send a note.
“This isn’t gonna be good“, I assumed. Correctly.
After I left Telerik for Google in 2016, development on the “Fiddler Classic” application had stagnated as the owners put their investments into a series of products they could monetize.
To be fair, this pivot was not unexpected. Initially, Telerik had purchased Fiddler largely for the community attention — the tool had a huge userbase of the exact developers the company was courting — we always expected that eventually we’d have a cross-platform version of the product that could be sold like Telerik’s other professional tools.
Fiddler: Free Forever?
Telerik had loudly promised that Fiddler would remain “free forever” to avoid expected community outrage about commercializing a previously-free tool. Before Telerik, I had spoken to one potential acquirer who estimated the brand damage of their commercializing another previously-free tool at 25x their acquisition price, meaning they’d likely never turn a profit.
Telerik’s blog post announcing the change was explicit:
… but even that wasn’t enough, so a follow-up post was made shortly after:
The unambiguous clarity of this promise had somewhat painted Telerik into a corner– they’d either need to find new ways to 1) monetize the technology behind Fiddler (we had several solid ideas), or 2) pivot to a new cross-platform product they could sell, or 3) renege on their promise and start charging for Fiddler for Windows.
While I was at Telerik, I worked a little on #1 — we created a licensable version of FiddlerCore, the core engine inside Fiddler, with the idea that other companies could sell products based on it. They had used FiddlerCore inside Telerik’s Test Studio product (that’s how I came to their attention to start with), and we figured other companies might need similar technology. Interest was… not very high.
Very frustratingly and humiliatingly, my former employer wanted to use FiddlerCore inside their Message Analyzer product. But they didn’t want to pay for it. So instead, a juggernaut worth hundreds of billions of dollars wrote code to prompt the end-user to pirate FiddlerCore:
This is the sort of behavior then most often seen from shady apps trying to avoid paying MP3 patent fees. To this day, I remain shocked that the lawyers from both companies allowed this experience to ship. (The fact that Microsoft-ecosystem developers made up virtually all of Telerik’s customers probably had something to do with Telerik not suing their pants off).
I had also started work on strategy #2 (build a cross-platform version) shortly after I started at Telerik. I spent months trying to get Fiddler running on Mono, an early cross-platform version of the .NET Framework. It didn’t go great. I built a serviceable version for Linux, but the UI port for MacOS would crash constantly. A hybrid strategy, using Mono for FiddlerCore, and building a new front-end on Electron, seemed plausible though. Alas, this vision had been put on pause in 2014 when Telerik conducted wide US-based layoffs in advance of an expected IPO on the US stock market. After its acquisition by Progress, Telerik eventually restarted this strategy, eventually shipping Fiddler Everywhere, a product that had a few key advantages over Fiddler Classic (cross platform! some team features!) and a lot of downsides (no extensibility model).
I’d hoped that Progress/Telerik might open-source Fiddler Classic at some point to grow the ecosystem (things like the Fiddler SAZ format would get even more popular and create the possibility of sellable synergies) but this never happened. Instead, Fiddler just quietly decayed. As browsers adopted new standards (e.g. http2, h3, GREASE, tls1.3, zstd content compression), Fiddler Classic required more and more caveats for use. However, Fiddler’s rich extensibility model means that I could keep building new capabilities in and on Fiddler in the ten years since I’ve been able to commit updates to Fiddler itself.
I still use Fiddler almost every single day, but in many cases I’m not even using Fiddler to capture traffic anymore, instead just using it as a viewer for traffic captured natively by Chromium, or to use its TextEncoder and inspectors, or even as a frontend for other tools.
Telerik periodically added surveys and ads to the Fiddler Classic UI, and even if they were gratingly misleading, they weren’t too annoying.
Other changes of dubious value were also mildly annoying at worst.
This Week’s Rug Pull
Opening Fiddler on Monday, I was presented with a FiddlerUpdate announcement, including some neat improvements, particularly support for ZSTD decompression (obsoleting my workaround):
However, I didn’t accept the update straight away because I suspected something was afoot. (I also got distracted because Windows complained about the installer’s signature).
Sure enough, the first screen of the installer mentions another IMPORTANT change in Fiddler that was not mentioned in that shiny update announcement:
Progress Telerik has decided to start demanding Fiddler Classic not be used for “commercial” purposes. Beyond the new text in the license, Fiddler shows this big orange bar:
So… it appears that the owners of Fiddler have reneged on their promise to the community and the product is no longer free.
Dialogue with Progress/Telerik
Taken literally, the license agreement says you cannot use Fiddler Classic for commercial purposes, even if you pay! This is rather shocking, because it means that Fiddler’s most engaged users, who’ve built extensions and workflows around Fiddler, cannot use them, even if they’re willing to pay up. Such a position seems so wildly foolish that I assumed it must just be an oversight. I inquired, and Progress Telerik provided the following statement:
No, Progress is not planning to offer Fiddler Classic under a paid licence.
We recognise the important role Fiddler Classic has played in supporting developers’ debugging workflows over many years. Continuing to invest in the product at the level required for commercial and enterprise customers, including ongoing feature development and platform modernisation, is not aligned with our long-term product strategy. Accordingly, in recent years, Progress has focused on maintaining and supporting Fiddler Classic, while directing its development efforts towards Fiddler Everywhere.
That said, we recognise the value of the extensibility capabilities available in Fiddler Classic. As a result, we will continue to work on scripting functionality in Fiddler Everywhere to help users continue their existing workflows with minimal disruption. We will also continue to evaluate additional feature requests based on customer needs and use cases. As always, we remain open to feedback and are committed to understanding how we can best support our users.
Improved scripting functionality may satisfy some users, but it definitely will not encompass the wide range of scenarios enjoyed by Fiddler Classic today, especially for users who’ve built custom Inspectors, Transcoders, or other extensions that integrate Fiddler with other systems and processes used within their companies.
In a closing paragraph of their response, the Progress/Telerik product manager (or, more likely, their lawyer) appears to have attempted to suggest that I shouldn’t share my thoughts with you fine folks (emphasis mine):
Last but not at least, no person outside Progress is authorized to make announcements, provide comments, or respond to customers’ inquiries regarding Progress’ business on behalf of the company. All questions should be directed to Progress’ official communication channels fiddler@progress.com.
Needless to say, I don’t speak on behalf of my former employer, but they’re also not going to stop me from talking about this change.
My Feelings
Some folks have asked how I feel about this. In short, disappointed, somewhat betrayed, but ultimately not surprised. Fiddler for Windows is a powerful tool that provides a tremendous amount of value to its users, and the nature of short-term profit maximization is that companies with valuable assets often struggle to recognize the long-term value of not abusing their users.
As I talked about previously in my post about mistakes I made when building Fiddler, my lack of a monetization plan was a key shortcoming in the product’s strategy. When Telerik acquired Fiddler, I assumed that the business folks there would develop a strategy beyond “monetizing the eyeballs” of the tens of thousands of weekly downloaders (although it was a bargain for that traffic acquisition alone).
As I’ve described above, development of a monetizable product strategy never got any real attention. Meanwhile, the team over at Postman hypothesized that a team-based product would be a winner, they tailored their offering accordingly, and their valuation skyrocketed to $5.6B after $433M in VC funding. I suspect that Postman’s true pre-IPO valuation may be lower, but for perspective, Progress Software’s entire market capitalization is currently just $1.7B.
I was excited to recently see Progress move Fiddler Everywhere toward the hottest trend in tech (Artificial Intelligence) by introducing support for MCP and the popular agents. Done right, this could be a killer feature that people are willing to pay big money for because of the value it can deliver.
However, I worry that Progress may have just vaporized the trust and goodwill that would’ve smoothed their plan to move users from a solid (if outdated) free product to an actively-developed paid product with a disjoint feature set. That’s especially true because Fiddler’s Session Archive Zip (SAZ) format could’ve allowed compatibility between the two.
Where Do We Go From Here?
Many Fiddler Classic users can happily continue to use the product for free for their personal non-commercial needs. Some Fiddler Classic customers may be happy to switch to Fiddler Everywhere with prices starting at $84/user/year for a feature-limited version of the product, or $444/user/year for the full Fiddler Everywhere feature set (which does not, as noted above, have all of Fiddler Classic’s features or compatibility with its extensions).
Some users have told me that they’ve be taking measures to disable Fiddler 5.x’s upgrade logic and remain on the final free version forever under its original license. They’ll use the extensibility model to keep it compatible with the modern web. Unfortunately, public redistribution of the older installer is not permitted under its license.
Some users will likely just stop using Fiddler entirely. As browser developer tools have evolved, many web developers’ needs are now fully met by the Network tab in their respective browsers.
Some users will likely move to competitive products, whether pay (Postman, Charles) or free open-source (mitmproxy).
Fiddler -> CLeARINET?
One thing that’s particularly baffling about Progress’ decision is the timing. Crippling Fiddler might’ve made some (evil) sense back in 2020 or so, but if you haven’t noticed, times have changed.
- AI agents have enabled vibe-coding of production-quality code rapidly and cheaply. When a pre-Telerik acquirer asked me how long it would take them to implement their own, I guessed about 2000 hours, or about 700 if I guided them. Using an AI coding agent, I suspect you could get 90% of the way there in about 160 hours.
- Much of the work in building Fiddler was in “figuring stuff out”, and the resources for doing that are dramatically better than ever before: we have better blogs, better tooling, better RFCs, and more open-source code than ever before.
- The .NET platform is dramatically more capable (particularly related to async) than the v2.0 framework that Fiddler mostly targeted. I’ve already laid out a set of mistakes and pitfalls to avoid.
- There’s a large community of .NET developers who might be interested in lending a hand, including many hundreds that recently voluntarily retired from Microsoft. And there are some amazingly bright contributors who have built extensions and other code for legacy Fiddler who might jump at the chance to get their PRs into an open-source replacement.
- Fiddler has no “moat” — the SAZ file format is simple and easily read and written. The product is designed to interact with protocols and formats based on open-standards. The true value of Fiddler was almost entirely “goodwill.”
Times seem ripe for a change.
When I named Fiddler, I did so because I was on the Microsoft Office clipart team and I knew we had plenty of free pictures of violins handy. Time has passed, and we have AI that can generate any images we want. An important kid in my life plays clarinet. If you squint at it, Clarinet sounds kinda like “Clear INET”, and seeing internet traffic in the clear is the whole point here.
In about 5 minutes, we’ve got a name, a domain, and a splash screen.
Now we just need some code. :)
Appendix: Fiddler Origins
This section is from the Fiddler Book.
First, a confession—the Fiddler Web Debugger is not the result of a grand vision or the ambition to develop the world’s most popular debugging proxy. A tool born of necessity, I never set out to build a platform so flexible, powerful, and complicated that I’d be forced to spend a year writing a book to explain how to fully take advantage of it. But here we are.
Before diving into the technical chapters, I will begin by sharing the story behind how Fiddler came to be.
As a student at the University of Maryland in the spring of 1999, I had the chance to interview for a Program Management internship on a new team at Microsoft. One of my final interviewer’s first questions was “How does HTTP work?” Knowing only the basics, I gave an incomplete and somewhat inaccurate answer, but didn’t embarrass myself too badly. That summer and the following, I worked on features for the first version of SharePoint. On rare occasions, I found myself looking at web traffic in Microsoft Network Monitor (NetMon), a powerful but then primitive and difficult-to-use packet sniffer. In the early summer of 2001, I joined Microsoft full-time as the Program Manager for the Office Clip Art client and website.
At that time, most of the developers and testers working on my team were new to web development, having previously been responsible for writing native code applications in C and C++. It was quickly apparent that the debugging process was overly cumbersome—many of my colleagues were loath to use NetMon. I even watched some developers debugging HTTP requests by hovering over variables in Visual Studio, examining the raw traffic in hex:
Having developed several small Windows utilities, I was confident that I could code something to make web debugging simpler. My first simplistic effort was based on taking an existing C++ proxy server and making minor modifications to it so that it would spew HTTP traffic to the system console:
It’s generous to call this effort primitive—the proxy couldn’t handle secure traffic or authentication protocols. Non-text content was another problem—comically, the utility would try to render binary content as ASCII. Old-school console users may recall that the octet 0x07 represents the “bell” character, and when it’s displayed in the console, a system beep is played. Soon after its release, the hallways of the Office Online team sounded like a Las Vegas casino, as binary content flowed through the debug proxies running in each tester’s office.
Despite the very annoying limitations, this tool was still popular, and I was inspired to get started on the next version. I mocked up a quick little demo in Borland Delphi, a native code language used for most of my development work at the time. The colorful UI foreshadowed Fiddler’s eventual appearance:
However, as I pondered the security and memory-management implications of writing a proxy server in native code, I soon decided that my next effort would be developed in C#, a new language being developed by the Visual Studio team that my best friend had just joined. The notion of writing a HTTP proxy server from scratch in .NET posed just two significant challenges: I didn’t really know how HTTP worked, and I didn’t know how to code in C#.
Fortunately, given a few trips to the bookstore and a lot of spare weekends, both shortcomings would be remedied. Two books were my constant companions: HTTP: The Definitive Guide and the C# Cookbook. Chapter by chapter, I learned about HTTP and C#, and week-by-week Fiddler came to life. About six months after I started, I had a basic version of Fiddler ready:
Like its predecessors, it too had a large number of limitations (and thousands of bugs) but it was eagerly adopted by colleagues whose PC speakers were in danger of burning out from the incessant beeps of my first proxy utility.
Over the subsequent years, Fiddler was progressively enhanced with two extensibility models, a mechanism to automatically generate and modify responses, and support for secure (HTTPS) traffic, FTP, and HTML5 WebSockets. In 2012, Fiddler was ported to the Mono Framework, enabling it to run directly on Mac and Linux PCs and virtual machines.
Appendix: Progress Announcement
