Fiddler is an HTTP debugging proxy that sits between a client application and the server it contacts. It records each request and response as a session, then exposes the URL, method, headers, body, status, timing, and transfer size. A browser developer panel sees traffic from one browser context. Fiddler can capture several applications or a separately configured device when their connections pass through its proxy.
Follow one session
The Live Traffic grid gives every request and response pair its own row. Selecting a session opens inspectors suited to the body format, while the overview retains protocol and timing facts. Filters can isolate one host, status, content type, or process so background requests do not bury the transaction under investigation.
A failed screen action often generates several sessions: an API request, an authentication refresh, and image or script fetches. Fiddler preserves their order and lets the user compare two sessions. Saving a snapshot keeps the evidence after the live application closes, but the saved capture can contain tokens, cookies, form data, and response content that should not be shared casually.
HTTPS needs trust
Fiddler captures ordinary HTTP through its proxy without decrypting it. HTTPS protects the payload with TLS, so inspection requires Fiddler to create a local certificate authority and place its certificate in a trusted store. Fiddler then establishes one secure connection with the client and another with the real server, which lets the inspectors read the traffic between them.
This step changes the machine’s trust configuration. User-store trust affects the current user, while machine-store trust affects all users and requires administrator rights. Some systems require manual certificate installation. Removing the Fiddler certificate disables later HTTPS inspection and is appropriate when the machine no longer needs that debugging setup.
Certificate pinning or a private trust policy can still stop an application from accepting Fiddler’s generated certificates. An empty capture does not always mean the application made no request; it may bypass the system proxy or reject the interception certificate.
Replay the request
Composer turns a captured request into an editable request or starts a new one with a chosen method, URL, headers, and body. It can send the same API call after one atomic change, which separates a server behavior from the surrounding client interface. Collections keep related requests together for later checks.
A replay can create, update, or delete real server data when the selected HTTP method and credentials permit it. Fiddler does not convert a production endpoint into a test environment. Before executing a captured request, the user should inspect its host, authorization header, payload, and side effects.
Rules alter traffic
Rules match sessions by conditions and then change the request or response. A rule can return a local file, replace a header, introduce a delay, or mock a status without editing either application. This makes it possible to test failure handling while the client continues to call its normal URL.
Several active rules can touch the same session in their configured order. A broad host match can therefore alter unrelated requests, and one rule can change the input seen by the next. Disabling completed experiments and keeping conditions narrow prevents an old mock from being mistaken for live server behavior.
Fiddler’s ignore-certificate-errors option removes another diagnostic safeguard. Enabling it for every site can hide a genuine invalid server certificate and expose ordinary browsing to spoofing. A specific development endpoint is a safer scope when that exception is unavoidable.
