Custom Fiddler Inspectors: Extend HTTP Debugging Power

Why Custom Inspectors Elevate Your Fiddler Debugging Workflow

Fiddler isn’t just a passive HTTP proxy — it’s a programmable debugging platform. While the built-in inspectors (Raw, JSON, WebForms, TextView) cover common use cases, real-world API testing, legacy protocol analysis, or domain-specific validation often demands deeper inspection logic. Building custom Fiddler inspectors unlocks granular control over how requests and responses are parsed, visualized, and validated — turning Fiddler into a tailored HTTP debugging toolkit.

This capability is especially valuable when working with non-standard headers, binary payloads, encrypted segments (e.g., custom JWT wrappers), or proprietary serialization formats. It also complements more tutorials on HTTPS decryption and advanced session manipulation — because once you’ve decrypted TLS traffic, you’ll want to interpret it meaningfully.

Prerequisites: Environment Setup & Toolchain

Before writing code, ensure your environment supports Fiddler extensibility:

• Fiddler Classic v5.0.20234.57100+ (or latest stable) — older versions lack full .NET 6+ support and modern inspector APIs.
• .NET SDK 6.0 or later — Fiddler extensions are compiled as .NET class libraries targeting net6.0 or net8.0.
• Visual Studio 2022 (Community or higher) or VS Code with C# extension — for editing and building.
• Fiddler’s Extensions folder: Typically %USERPROFILE%\Documents\Fiddler2\Scripts\Inspectors (Classic) or %LOCALAPPDATA%\Programs\Fiddler\Inspectors (v6 beta). Confirm path via Tools > Options > Extensions.

💡 Tip: Enable Tools > Fiddler Options > Extensions > Enable Extensions and restart Fiddler after deploying a new inspector DLL.

Anatomy of a Custom Inspector: Core Interfaces

Every Fiddler inspector implements one or both of these interfaces from FiddlerCore:

• IInspector2: The modern interface (recommended). Supports async rendering, rich UI via WinForms/WPF, and lifecycle events (Init, Cleanup, UpdateView).
• IInspector: Legacy interface — synchronous only, limited UI flexibility. Avoid unless maintaining older extensions.

Your inspector must also inherit from UserControl (WinForms) or FrameworkElement (WPF) and be decorated with [InspectorAttribute]. Here’s the minimal skeleton:

using Fiddler;
using System.Windows.Forms;

[InspectorAttribute("MyProto", "My Protocol Viewer", "text/x-myproto")]
public partial class MyProtoInspector : UserControl, IInspector2
{
    public MyProtoInspector() => InitializeComponent();

    public void Init(Session oSession) { /* Load session data */ }
    public void Cleanup() { /* Release resources */ }
    public void UpdateView() { /* Refresh UI */ }
    public bool IsReadOnly => false;
    public void OnCommit() { /* Save changes back to session */ }
}

The "text/x-myproto" MIME type tells Fiddler when to auto-activate this inspector — e.g., when Content-Type: text/x-myproto appears in a request/response header.

Step-by-Step: Build a JSON Schema Validator Inspector

Let’s build a practical example: an inspector that validates JSON responses against a user-defined JSON Schema and highlights violations inline.

1. Create the Project & Dependencies

dotnet new classlib -n FiddlerJsonSchemaInspector -f net6.0
cd FiddlerJsonSchemaInspector
dotnet add package Newtonsoft.Json
dotnet add package NJsonSchema

Add reference to FiddlerCore (download FiddlerCore.dll from telerik.com/fiddler/fiddlercore and reference locally):

dotnet add reference "C:\Program Files\Fiddler\FiddlerCore.dll"

2. Implement the Inspector Logic

In JsonSchemaInspector.cs, extend the skeleton:

[InspectorAttribute("JsonSchema", "JSON Schema Validator", "application/json")]
public partial class JsonSchemaInspector : UserControl, IInspector2
{
    private TextBox txtSchema = new TextBox { Dock = DockStyle.Top, Height = 100 };
    private RichTextBox txtOutput = new RichTextBox { Dock = DockStyle.Fill };
    private Session _session;

    public JsonSchemaInspector() {
        this.Controls.Add(txtSchema);
        this.Controls.Add(txtOutput);
        txtSchema.Text = "{\"type\":\"object\",\"required\":[\"id\"]}";
    }

    public void Init(Session oSession)
    {
        _session = oSession;
        UpdateView();
    }

    public void UpdateView()
    {
        if (_session?.oResponse?.BodyString == null) return;

        try
        {
            var schema = NJsonSchema.JsonSchema.FromJsonAsync(txtSchema.Text).Result;
            var json = JToken.Parse(_session.oResponse.BodyString);
            var errors = schema.Validate(json);

            txtOutput.Clear();
            if (errors.Count == 0)
                txtOutput.AppendText("✅ Valid JSON against schema.");
            else
            {
                txtOutput.AppendText($"❌ {errors.Count} validation error(s):\n");
                foreach (var err in errors.Take(10))
                    txtOutput.AppendText($"- {err.Path}: {err.Message}\n");
            }
        }
        catch (Exception ex)
        {
            txtOutput.AppendText($"⚠ Schema parse error: {ex.Message}");
        }
    }

    public void Cleanup() { }
    public bool IsReadOnly => true;
    public void OnCommit() { }
}

3. Compile & Deploy

Build and copy the output DLL to Fiddler’s Inspectors folder:

dotnet build -c Release
copy bin\Release\net6.0\FiddlerJsonSchemaInspector.dll "%USERPROFILE%\Documents\Fiddler2\Scripts\Inspectors\"

Restart Fiddler. When inspecting a JSON response, select Inspectors > JSON Schema Validator from the dropdown — or let it auto-activate for application/json.

🔒 Note: This inspector works seamlessly alongside Fiddler’s native HTTPS decryption — decrypt first, then validate.

Advanced Patterns: Async Rendering & Dynamic MIME Binding

For large payloads (e.g., base64-encoded images or protobuf dumps), avoid blocking the UI thread:

public async void UpdateView()
{
    await Task.Run(() => {
        // CPU-heavy parsing here
        var decoded = Convert.FromBase64String(_session.oResponse.BodyString);
        var summary = AnalyzeBinaryHeader(decoded);
        this.Invoke((MethodInvoker)delegate {
            txtSummary.Text = summary;
        });
    });
}

To bind inspectors dynamically — not just by MIME type — override GetSupportedContentTypes():

public IEnumerable<string> GetSupportedContentTypes()
{
    yield return "application/json";
    yield return "text/plain"; // fallback
    // Or check headers at runtime:
    if (_session?.oResponse?.Headers?.ExistsAndContains("X-Protocol", "my-custom") == true)
        yield return "*/*";
}

This flexibility makes custom inspectors indispensable for browse Advanced Techniques tutorials, especially when reverse-engineering undocumented APIs.

Troubleshooting Common Pitfalls

Issue	Diagnosis	Fix
Inspector doesn’t appear	Check Fiddler log (Help > About Fiddler > View Log) for assembly load exceptions.	Ensure target framework matches Fiddler’s runtime (.NET 6/8). Verify FiddlerCore.dll version compatibility.
UI renders blank or throws NullReferenceException	Init() wasn’t called before UpdateView().	Never assume _session is populated in constructor — always defer logic to Init() or UpdateView().
Changes don’t persist after tab switch	Inspector isn’t implementing OnCommit() or IsReadOnly = false.	Set IsReadOnly = false, implement OnCommit() to write back to oSession.oRequest.BodyBytes or oResponse.BodyString.
HTTPS decryption fails with custom inspectors enabled	Rare, but can occur if inspector modifies oSession headers mid-decryption.	Avoid mutating oSession.oRequest.headers or oResponse.headers inside inspectors — those hooks fire after decryption completes.

Also verify your inspector DLL isn’t blocked by Windows (right-click → Properties → Unblock if flagged).

Beyond the Basics: Real-World Use Cases

• gRPC-Web Inspector: Parse application/grpc-web+proto payloads, decode binary trailers, and render Protobuf messages using Google.Protobuf.
• OAuth2 Token Debugger: Auto-extract and decode JWTs from Authorization: Bearer <token>, validate signatures (with optional key upload), and highlight exp, aud, and scope.
• GraphQL Query Analyzer: Highlight syntax errors, extract operation names/types, and warn about over-fetching (e.g., __typename sprinkling or deep nesting).
• Legacy EDI/XML Payload Formatter: Normalize ANSI X12 or HL7 segments, colorize functional groups, and flag missing mandatory segments.

Each of these extends Fiddler’s role beyond generic HTTP debugging into domain-specific observability — critical for QA engineers validating integrations or security researchers auditing auth flows.

Conclusion: Your Fiddler, Fully Programmable

Custom Fiddler inspectors transform Fiddler from a read-only HTTP proxy into an extensible, domain-aware debugging environment. With just a few dozen lines of C#, you can enforce API contracts, decode proprietary formats, or visualize complex relationships in traffic — all while retaining full compatibility with core features like HTTPS decryption and auto-capture rules.

Key takeaways:

• Always target .NET 6.0+ and reference the correct FiddlerCore.dll.
• Prefer IInspector2 over IInspector for async support and future-proofing.
• Leverage MIME types and dynamic header checks to activate inspectors contextually.
• Test under real fiddler debugging conditions — especially with compressed, chunked, or streaming responses.
• Remember: great fiddler tutorial content starts with solving your actual pain points — not hypothetical ones.

Whether you’re deep in API integration, hardening a microservice mesh, or auditing third-party SDK behavior, custom inspectors put precision insight at your fingertips. Start small, iterate fast, and ship value — not just code.

Need help adapting this pattern to your stack? contact us for architecture review or extension mentoring.