Mastering AutoResponder Regex Patterns in Fiddler

Fiddler’s AutoResponder is far more than a static file-swap tool — it’s a precision HTTP debugging instrument when paired with regex pattern matching. Developers and QA engineers routinely use it to simulate backend failures, test edge-case responses, or isolate frontend behavior without touching production APIs. Yet most users stop at simple URL matching, missing out on the full power of regex-driven request interception — especially critical when working with dynamic endpoints, versioned APIs, or complex query parameters.

This guide walks through advanced AutoResponder patterns that transform your fiddler debugging workflow. You’ll learn how to match paths, headers, methods, and even response status codes — all while maintaining HTTPS decryption integrity and avoiding common pitfalls.

Why Regex-Powered AutoResponder Beats Basic Matching

Basic AutoResponder rules rely on literal string matching (e.g., https://api.example.com/v2/users). That works for fixed routes, but fails when:

URLs include dynamic IDs (/users/12345), timestamps, or hashes
Query strings vary unpredictably (?ts=1718924032&v=2.1.0)
You need to target only POST requests to /login, not GET
You want to override responses only when a specific header (e.g., X-Env: staging) is present

Regex unlocks conditional, context-aware matching — essential for realistic http debugging scenarios. And because AutoResponder operates after Fiddler decrypts HTTPS traffic (assuming https decryption is enabled), you can safely apply these patterns to secure endpoints without breaking TLS inspection.

Enabling Regex Mode and Understanding Syntax

AutoResponder defaults to exact match mode. To enable regex:

Open Rules > Customize Rules (or press Ctrl+R)
In the OnBeforeRequest section, ensure oSession.utilDecodeRequest(); is called (required for query/header access)
In the AutoResponder tab (Rules > AutoResponder), check Enable rules and Unmatched requests passthrough
Click Add Rule, then toggle the regex checkbox next to the Match condition field

⚠️ Important syntax notes:

Fiddler uses .NET’s Regex.IsMatch() — so patterns follow ECMAScript-compatible regex
Anchors (^, $) refer to the entire matched string — typically the full request URL including scheme and port
Case sensitivity is on by default. Append (?i) to make it case-insensitive
To match query parameters, use oSession.fullUrl (not just oSession.url) — this includes the full URL with query string

Example: ^https?://api\.example\.com/v\d+/users/\d+$ matches /v1/users/999 and /v2/users/12345, but not /v2/users/me.

Matching Requests by Method, Headers, and Body Content

AutoResponder alone doesn’t evaluate HTTP methods or headers — but you can combine it with FiddlerScript for full control.

Step-by-step: Conditional Rule Using FiddlerScript

Go to Rules > Customize Rules
Scroll to static function OnBeforeRequest(oSession: Session)
Add this block before any existing if logic:

if (oSession.hostname == "api.example.com" && 
    oSession.RequestMethod == "POST" && 
    oSession.oRequest.headers.Exists("X-Test-Mode") && 
    oSession.GetRequestBodyAsString().Contains("paymentMethod":)) {
    oSession.bBufferResponse = true;
    oSession.utilSetResponseBody("{\"error\":\"simulated decline\"}");
    oSession.responseCode = 402;
    oSession.oResponse.headers.SetStatus(402, "Payment Required");
    return;
}

This bypasses AutoResponder entirely — but achieves what regex alone cannot: method + header + body logic. Use this when AutoResponder’s regex-only model falls short.

For lighter-weight header-based routing within AutoResponder:

Enable Match request headers in AutoResponder settings
Click Add Header Match, then enter X-Env → staging
Combine with a regex URL pattern like ^https?://api\.example\.com/.*$

Note: Header matching is AND-combined with URL matching — both must pass.

Advanced Regex Patterns for Real-World APIs

Here are battle-tested patterns used in production fiddler proxy workflows:

Pattern 1: Version-Agnostic API Path Matching

^https?://api\.example\.com/v\d+/(users|products|orders)/\d+$

Matches /v1/users/42, /v3/products/777, etc.
Uses alternation (users|products|orders) to cover multiple resource types
Escapes dots (\.) and anchors (^, $) for strictness

Pattern 2: Query String Parameter Capture & Reuse

^https?://api\.example\.com/search\?(?=.*q=)(?=.*limit=\d+).*$

Uses positive lookahead (?=...) to require both q= and limit=
Avoids false positives from partial matches (e.g., q=foo&limit=10&sort=asc ✅ vs q=foo ❌)

Pattern 3: Dynamic ID with Exclusion

^https?://api\.example\.com/users/(?!me$|current$)\d+$

Uses negative lookahead (?!me$|current$) to exclude /users/me and /users/current
Still matches /users/123, /users/99999, etc.

💡 Pro tip: Test regex live using Tools > Test Regex — paste sample URLs and validate before deploying.

Chaining Rules and Priority Management

AutoResponder evaluates rules top-down. Order matters — and overlapping patterns can silently shadow each other.

Best practices:

Place specific rules above generic ones (e.g., /v2/users/123 before /v2/users/\d+)
Use Disable rule (uncheck the box) instead of deleting — preserves history and comments
Add descriptive comments: right-click a rule → Edit Comment
For complex logic, group related rules under collapsible sections using # Group: Auth Simulation

To force priority without reordering, prepend high-priority patterns with ^ and anchor tightly — loose patterns like .* will match everything unless placed last.

Also remember: AutoResponder only intercepts requests — it does not modify responses after they’re generated. So if you need to rewrite Set-Cookie, Location, or Content-Type, use Rules > Customize Rules with OnBeforeResponse instead.

Troubleshooting Common Regex Pitfalls

Even experienced developers hit these snags. Here’s how to resolve them fast:

❌ “Rule isn’t firing”

Verify Enable rules is checked in AutoResponder tab
Confirm Unmatched requests passthrough is enabled (otherwise unmatched requests hang)
Check oSession.fullUrl in QuickExec: type url → press Enter to see exact value being matched
Ensure HTTPS decryption is active (Tools > Options > HTTPS > Decrypt HTTPS traffic) — otherwise fullUrl may be incomplete or masked

❌ “Regex matches too broadly”

Replace .* with tighter patterns: [^?#]* (anything except ? or #) or [^&]* (up to next query param)
Always use ^ and $ unless intentionally allowing substring matches
Escape special characters: ., +, ?, *, (, ) — e.g., example\.com, not example.com

❌ “Special characters break the rule”

AutoResponder UI auto-escapes some chars, but not all. When pasting regex, wrap in raw strings if possible (not supported in UI — so double-escape manually: \\. for a literal dot)
Avoid Unicode or non-ASCII in patterns — stick to ASCII regex for reliability

❌ “Headers aren’t matching despite correct values”

Header names are case-insensitive per HTTP spec, but Fiddler stores them as received — prefer oSession.oRequest.headers.Exists("X-Api-Key") over regex on raw header string
Use oSession.oRequest.headers.Text to inspect exactly what’s present

Conclusion: From Static Swaps to Intelligent Interception

AutoResponder regex transforms Fiddler from a passive traffic viewer into an intelligent, programmable fiddler tutorial toolkit. With precise pattern matching, header awareness, and tight integration into Fiddler’s HTTPS decryption pipeline, you gain surgical control over how requests behave — without modifying code, restarting servers, or coordinating with backend teams.

Key takeaways:

Always anchor regex with ^ and $ unless substring matching is intentional
Prefer header-based filtering over URL regex when possible — it’s faster and more readable
Combine AutoResponder with FiddlerScript for method-, body-, or response-status logic
Validate patterns using Tools > Test Regex, and verify decrypted URLs via QuickExec
Prioritize rules carefully — order defines execution flow

Ready to level up further? browse Request Modification tutorials for session injection, latency simulation, and conditional breakpoints. Or explore how more tutorials cover HTTPS decryption nuances, WebSocket inspection, and CI-integrated Fiddler scripting. Have a complex use case? contact us — we help teams build robust, maintainable Fiddler automation.