Fiddler + Selenium WebDriver: Capture & Analyze HTTP Traffic

Why Combine Fiddler with Selenium WebDriver?

Modern web automation rarely stops at clicking buttons and validating text. When tests fail silently, when APIs return unexpected payloads, or when third-party scripts interfere with your flow — you need visibility into the actual HTTP exchange. That’s where Fiddler debugging becomes indispensable. Integrating Fiddler with Selenium WebDriver transforms your test suite from a black box into a fully observable system — enabling precise http debugging, session replay, request manipulation, and robust https decryption for secure endpoints.

Unlike browser devtools (which vanish on headless execution), Fiddler runs as a system-wide fiddler proxy, capturing all traffic — including XHRs, fetch calls, WebSocket handshakes, and background service workers — regardless of how Selenium launches Chrome, Edge, or Firefox. This integration is especially powerful for API-driven applications, SSO flows, and microservice-heavy architectures.

This guide walks you through a production-ready setup: configuring Fiddler as a local proxy, forcing Selenium to route traffic through it, decrypting HTTPS without certificate errors, and extracting actionable insights from captured sessions.

Prerequisites & Setup

Before integrating, ensure these components are installed and configured:

Fiddler Classic (v5.0.20234.58916 or newer) — Download from Telerik
Java 11+ or .NET 6+, depending on your Selenium binding
Selenium WebDriver bindings (e.g., selenium-java v4.15+ or Selenium.WebDriver NuGet v4.15+)
ChromeDriver / GeckoDriver / EdgeDriver, matching your browser version

✅ Critical First Step: Launch Fiddler before running any Selenium code. By default, Fiddler listens on 127.0.0.1:8888. Confirm this under Tools > Options > Connections. Also enable Decrypt HTTPS traffic (under HTTPS tab) — this installs Fiddler’s root certificate and configures Windows trust. Without this, you’ll see <Protocol Error> for most modern sites.

For https decryption, ensure your OS trusts FiddlerRoot. On Windows, run certmgr.msc, navigate to Trusted Root Certification Authorities, and verify DO_NOT_TRUST_FiddlerRoot is present. On macOS/Linux, import FiddlerRoot.cer manually via Keychain Access or update-ca-certificates.

Configuring Selenium to Use Fiddler as Proxy

Selenium doesn’t auto-detect system proxies — you must explicitly configure it. Below are language-specific examples.

Java (WebDriverManager + ChromeDriver)

import org.openqa.selenium.Proxy;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

Proxy proxy = new Proxy();
proxy.setHttpProxy("127.0.0.1:8888")
     .setSslProxy("127.0.0.1:8888")
     .setFtpProxy("127.0.0.1:8888");

ChromeOptions options = new ChromeOptions();
options.setCapability("proxy", proxy);
options.addArguments("--ignore-certificate-errors"); // Required for Fiddler's self-signed cert

WebDriver driver = new ChromeDriver(options);
driver.get("https://httpbin.org/get");

⚠️ Note: --ignore-certificate-errors is not a security bypass — it’s necessary because Chrome blocks Fiddler’s dynamically generated certs unless explicitly allowed. With Fiddler’s root trusted, this flag can be omitted in production-grade environments.

C# (.NET 6+, Selenium.WebDriver)

var proxy = new Proxy
{
    HttpProxy = "127.0.0.1:8888",
    SslProxy = "127.0.0.1:8888"
};

var options = new ChromeOptions();
options.Proxy = proxy;
options.AddArgument("--ignore-certificate-errors");

using var driver = new ChromeDriver(options);
driver.Navigate().GoToUrl("https://httpbin.org/get");

Python (selenium 4.15+)

from selenium import webdriver
from selenium.webdriver.common.proxy import Proxy, ProxyType

proxy = Proxy({
    'proxyType': ProxyType.MANUAL,
    'httpProxy': '127.0.0.1:8888',
    'sslProxy': '127.0.0.1:8888'
})

options = webdriver.ChromeOptions()
options.proxy = proxy
options.add_argument('--ignore-certificate-errors')

driver = webdriver.Chrome(options=options)
driver.get('https://httpbin.org/get')

💡 Pro Tip: For headless mode, add options.add_argument('--headless=new'), but remember — Fiddler still captures all traffic. No visual browser needed.

Advanced Fiddler Features for Test Automation

Once traffic flows through Fiddler, you unlock powerful fiddler tutorial techniques beyond passive logging:

AutoResponder: Mock API Responses During Tests

Use AutoResponder (Rules > AutoResponder) to simulate slow responses, 500 errors, or stubbed JSON — without changing application code. Example:

Add rule: regex:^https?://api\.example\.com/v1/users.*
Set action to “Return ‘File’” → point to ./stubs/users-404.json
Enable “Unmatched requests passthrough”

Now every Selenium test hitting that endpoint gets your controlled response — ideal for testing error-handling logic.

Composer: Inject Custom Requests Mid-Test

Need to trigger a webhook or validate auth state before a test step? Open Composer (Ctrl+R), build a POST request with headers and body, then execute it while your test is paused. You can even save Composer sessions as .saz files for later replay.

Filters & Breakpoints: Isolate Critical Traffic

In Filters tab, enable “Use Filters”, then check “Show only the following hosts” → enter api.example.com to suppress noise.
Set breakpoints (F11 or Rules > Breakpoints) on specific URLs or methods (POST /login) to pause mid-request and inspect/modifiy headers or body before forwarding.

These capabilities make Fiddler more than a log viewer — it’s an active test orchestration layer.

Decrypting HTTPS Traffic Reliably

Many testers hit walls with https decryption due to certificate pinning, QUIC, or browser hardening. Here’s how to avoid common pitfalls:

✅ Disable QUIC: Chrome/Edge may fall back to QUIC (UDP-based), which Fiddler cannot intercept. Add this argument: --disable-quic.
✅ Bypass HPKP & Certificate Pinning: For Chromium-based browsers, use --unsafely-treat-insecure-origin-as-secure="https://localhost:8888" --user-data-dir=/tmp/fiddler-profile (note: only for local testing).
✅ Firefox users: Fiddler requires manual proxy config and disabling security.enterprise_roots.enabled in about:config to respect FiddlerRoot.

If you still see red lock icons or NET::ERR_CERT_INVALID, open Fiddler > Tools > Options > HTTPS and click Actions > Reset All Certificates, then re-enable decryption. Restart both Fiddler and your browser.

For deeper insight into TLS handshake failures, use Fiddler’s Inspectors > TextView to examine raw ClientHello — it reveals cipher suite mismatches or SNI issues.

Troubleshooting Common Integration Issues

Symptom	Likely Cause	Fix
No traffic appears in Fiddler	Selenium not using proxy, or Fiddler not running	Verify proxy config; check Fiddler’s status bar (“Capturing: Yes”)
HTTPS shows “Tunnel to…” but no decrypted content	HTTPS decryption disabled or cert untrusted	Re-run Fiddler’s HTTPS cert installer; check OS trust store
`ERR_PROXY_CONNECTION_FAILED` in browser	Port conflict (another app using 8888), or firewall blocking loopback	Change Fiddler port (Tools > Options > Connections); disable antivirus real-time scanning temporarily
Selenium hangs on `driver.get()`	Breakpoint active and not resumed	Press F11 in Fiddler to release, or disable breakpoints before test run
Mixed content warnings	HTTP resources loaded over HTTPS page	Use Fiddler’s Rules > Customize Rules and add `oSession.host == "insecure-cdn.com" && oSession.HTTPMethod == "GET" { oSession.utilCreateResponseAndBypassServer(); oSession.utilSetResponseBody("{}"); }`

Also note: Fiddler does not capture traffic from file:// URLs or Electron apps unless explicitly configured with --proxy-server=127.0.0.1:8888 CLI flag.

Extracting Data from Captured Sessions

Raw logs aren’t enough — you need structured data. Fiddler supports export in multiple formats:

File > Export Sessions > Selected Sessions > JSON → parse in Python/Java for assertions
File > Export Sessions > All Sessions > WebLog (NCSA) → feed into log analyzers like ELK
File > Export Sessions > Selected Sessions > Visual Studio Test Results (.trx) → integrate with CI pipelines

You can also automate extraction using FiddlerCore (C# library) or the Fiddler Everywhere CLI (fiddler-cli capture --port 8888 --output ./logs). For example, assert that every /checkout request includes X-Correlation-ID:

foreach (Session s in FiddlerApplication.AliveSessions)
{
    if (s.url.Contains("/checkout") && !s.oRequest.headers.Exists("X-Correlation-ID"))
        throw new InvalidOperationException("Missing correlation ID");
}

This bridges fiddler proxy observability with test assertions — turning debugging into validation.

Conclusion: From Debugging to Observability

Integrating Fiddler with Selenium WebDriver isn’t just about fixing flaky tests — it’s about building observable automation. With proper fiddler debugging, you gain full visibility into network behavior, accelerate root-cause analysis, and inject realism into test scenarios using AutoResponder and Composer. When combined with reliable https decryption, you eliminate guesswork around authentication flows, CORS misconfigurations, and CDN caching anomalies.

Key takeaways:

Always launch Fiddler first, confirm HTTPS decryption is enabled, and verify OS-level certificate trust.
Explicitly configure Selenium’s proxy — never rely on system defaults.
Leverage AutoResponder for contract testing and Composer for ad-hoc validation.
Export sessions programmatically to extend assertions beyond DOM checks.
Use Filters and Breakpoints to reduce noise and focus on what matters.

Mastering this integration places you ahead of teams relying solely on console logs or brittle waits. It’s the difference between reacting to failures and preventing them.

Ready to level up further? browse Advanced Techniques tutorials for headless FiddlerCore integrations, CI/CD pipeline hooks, and custom inspectors.