Diff HTTP Responses with Burp Suite Comparer (2026)

Burp Suite’s Comparer tool can highlight even the most subtle differences between two HTTP requests or responses, but understanding what you’re seeing requires more than just a visual diff.

Let’s say you’re debugging a web application and suspect a difference in how the server responds to slightly varied requests. You’ve captured two requests in Burp’s Proxy History, sent them both to the Comparer, and now you’re staring at a screen full of red and green.

Here’s a request that might have been sent, and the server’s response:

GET /api/users?id=123 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: session=abc123xyz

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 150
Date: Tue, 25 Jul 2023 10:30:00 GMT
Server: Apache
Set-Cookie: session=def456uvw; Path=/; HttpOnly; Secure
Cache-Control: no-cache

{
  "id": 123,
  "username": "alice",
  "email": "alice@example.com",
  "roles": ["user", "admin"]
}

And here’s a slightly modified request and its response:

GET /api/users?id=124 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: session=abc123xyz

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 145
Date: Tue, 25 Jul 2023 10:30:05 GMT
Server: Apache
Set-Cookie: session=ghi789xyz; Path=/; HttpOnly; Secure
Cache-Control: no-cache

{
  "id": 124,
  "username": "bob",
  "email": "bob@example.com",
  "roles": ["user"]
}

When you load these into Burp’s Comparer, you’ll see the differences highlighted. The most obvious changes are in the JSON body, reflecting the different user IDs and their associated data. But look closer at the headers. The Content-Length has changed, as expected, because the JSON payload is different. The Date header is also different – this is normal, as it reflects the time the response was generated.

The key insight here is that the Set-Cookie header has changed significantly, even though the session cookie in the request remained the same. This tells you that the server is issuing a new session token for each user request, not reusing the existing one. This is a critical security and state management observation.

The Comparer tool fundamentally works by performing a byte-by-byte comparison of the two selected items. When you select two requests or two responses, Burp sends them to a dedicated Comparer tab. It then renders them side-by-side, with differing bytes or sequences of bytes highlighted in distinct colors. By default, added content is green, and deleted content is red. This visual representation allows you to quickly pinpoint where the divergence occurs.

Let’s consider the actual data shown in the diff:

• Request Headers: You might see differences in query parameters (like id=123 vs. id=124), Host headers if you’re testing across different domains or subdomains, or even User-Agent strings if you’re simulating different clients.
• Request Body: For POST or PUT requests, the request body is where you’ll see substantive differences in submitted data.
• Response Status Line: A change from 200 OK to 404 Not Found or 500 Internal Server Error is a major indicator of a problem.
• Response Headers: This is often the most revealing part. Differences in Content-Type, Content-Length, Set-Cookie, Location (for redirects), and caching directives (Cache-Control, Expires) can explain a lot about how the server is processing your request and what state it’s managing.
• Response Body: This is the actual content delivered to the client. Differences here could be anything from dynamic data to error messages or entirely different HTML structures.

The power of Comparer lies in its ability to reveal why a response might be different, not just that it’s different. If you’re seeing a 302 Found redirect in one case and a 200 OK in another, the diff will show you the Location header in the 302 response, telling you where the server intended to send the user. If the JSON payload changes, the diff shows you exactly which fields and values have been altered.

One of the most insightful, yet often overlooked, aspects of using Comparer is not just looking at the content differences, but at the metadata surrounding them. For example, when comparing responses that should be identical, you might find minor variations in the Date header, which is expected. However, if you see differences in ETag or Last-Modified headers, and the content itself is identical, it can indicate that the server is incorrectly calculating cache validation tokens, potentially leading to stale content being served. This is a subtle but crucial distinction for performance and correctness.

After you’ve identified and fixed the underlying cause of the discrepancies, the next challenge you’ll likely encounter is dealing with rate limiting or IP blocking if your debugging process was too aggressive.