Flow Comparison

When you’re debugging an issue, you often need to answer: “what changed between these two requests?” Maybe a request that worked yesterday now returns an error. Maybe replaying a request gives a different response. Maybe two seemingly identical API calls behave differently. Flow comparison lets you put any two flows side-by-side and see exactly what’s different — down to individual JSON fields, headers, and timing.

Think of it like a “track changes” view in a word processor, but for HTTP requests and responses. Differences are highlighted in color so you can spot them instantly without manually scanning through raw data.

How to Start a Comparison

There are two ways to compare flows:

“Compare with…” (Search)

1. Right-click any flow in the traffic list
2. Click “Compare with…” (magnifying glass icon)
3. A search dialog opens where you can find the second flow by URL, host, or path — you can even search across different sessions
4. Select the flow you want to compare against
5. The comparison view opens in the right panel, replacing the normal flow inspector

”Compare with Selected” (Quick)

1. Click a flow to select it (this is the “current” flow)
2. Right-click a different flow
3. Click “Compare with Selected” (arrows icon)
4. The comparison opens immediately, showing the selected flow on the left and the right-clicked flow on the right

Once the comparison is open, you can click the magnifying glass button in the header to search for a different comparison flow without closing the view.

Layout

The comparison replaces the flow inspector panel (right side of the screen) with a two-column layout separated by a thin vertical divider:

┌───────────────────────┬─┬───────────────────────┐
│  "Current" (left)     │ │  "Comparison" (right)  │
│  GET /api/products    │ │  GET /api/products     │
├───────────────────────┤ ├───────────────────────┤
│  URL Section          │ │  URL Section           │
├───────────────────────┤ ├───────────────────────┤
│  Response Section     │ │  Response Section      │
│  200 OK · 2.4 KB      │ │  500 Error · 156 B     │
│  142ms                │ │  89ms  (-53ms)         │
├───────────────────────┤ ├───────────────────────┤
│  Request Headers      │ │  Request Headers       │
│  Authorization: Bea...│ │  Authorization: Bea... │
│  X-Debug: true        │ │  (missing)             │
├───────────────────────┤ ├───────────────────────┤
│  Response Headers     │ │  Response Headers      │
├───────────────────────┤ ├───────────────────────┤
│  Request Body         │ │  Request Body          │
├───────────────────────┤ ├───────────────────────┤
│  Response Body        │ │  Response Body         │
│  "role": "user"       │ │  "role": "admin"       │
└───────────────────────┴─┴───────────────────────┘

The left column is always labeled “Current” (the flow you had selected in the traffic list) and the right is “Comparison” (the flow you picked to compare against). Each column header shows the HTTP method badge and URL path for quick identification.

Comparison Sections

The comparison view walks through every part of the request-response pair, section by section, showing what’s the same and what’s different.

URL Diff

Shows the full request URL of both flows side-by-side. If the URLs are different (even slightly — like a different query parameter or path segment), the comparison side is highlighted in amber/warning color. If they’re identical, both appear in the normal text color.

This is the first thing you check: are these requests even going to the same endpoint?

Response Summary

A compact overview comparing the key response metrics:

Metric	What’s Shown	How Differences Appear
Status code	The HTTP status code with color-coded badge (200 green, 404 amber, 500 red)	If the status codes differ, the comparison status gets a warning ring highlight
Response size	Human-readable size (e.g., “2.4 KB”)	Side-by-side comparison
Duration	How long the request took in milliseconds	Shows a delta: green -53ms (faster) or red +120ms (slower) compared to the current flow

If one flow has no response (connection failed, timeout), that side shows “No response” in grey.

Request Headers Diff

All request headers from both flows, merged into a single list and sorted alphabetically. Each header row is color-coded:

Color	Meaning	What It Tells You
No highlight	Header exists in both flows with the same value	Nothing changed for this header
Green background	Header exists only in the comparison flow (added)	The comparison request included an extra header that the current one didn’t
Red background	Header exists only in the current flow (removed)	The current request has a header that the comparison doesn’t — with strikethrough text on the value
Amber/yellow background	Header exists in both but with different values	Same header name, different value — the most common and interesting case

The section title shows a count of differences, like “Request Headers (3 diff)”. If there are no headers at all, the section is hidden.

Each row has a fixed-width column for the header name (160px) and a flexible column for the value. Long values wrap and break within their cells. Header names are displayed in cyan monospace font for quick scanning.

Response Headers Diff

Same format and color coding as request headers, but for the response headers. This is where you’ll spot differences in caching policies, CORS headers, content types, rate limit counters, and server-set cookies between the two responses.

Request Body Diff

Only shown when at least one of the two flows has a request body (POST, PUT, PATCH requests typically have bodies; GET requests usually don’t).

For JSON content (when both flows have application/json content type): Ghost performs structural JSON diffing — it parses both JSON bodies and recursively compares them field by field. The result is a table showing:

Column	What It Shows
Key	The JSON path to the field (e.g., user.address.city, items[0].quantity) — displayed in cyan
Current	The value in the current (left) flow
Comparison	The value in the comparison (right) flow

Each row is color-coded:

• Green — field exists only in the comparison (added)
• Red — field exists only in the current flow (removed)
• Amber — field exists in both but has a different value (changed) or different type (type_changed)

A legend at the top summarizes the counts: “3 only in Current, 2 only in Comparison, 5 changed”.

How JSON diffing works under the hood:

• Objects are compared key-by-key, recursively traversing nested objects
• Arrays compare their lengths (flagged if different) and the structure of their first element — this shows whether the array element schema changed without overwhelming the view with thousands of individual element comparisons
• Primitive values (strings, numbers, booleans, null) are compared directly
• If the types differ (e.g., a field that was a string in one flow and a number in another), it’s flagged as type_changed
• Values longer than 80 characters are truncated with ”…” for display, arrays show “Array(N)”, and objects show “{N keys}”

For non-JSON content (form data, XML, plain text, or when JSON parsing fails): Ghost falls back to a raw side-by-side display showing the full body text in each column. If the bodies are identical, the section is hidden entirely.

Response Body Diff

Same structural diffing as request body — JSON bodies get the recursive field-by-field comparison with color coding, and non-JSON content gets the raw side-by-side fallback. This is typically the most important section: “the server responded differently — exactly what in the response changed?”

Common discoveries in response body diffs:

• A field that was null is now populated (or vice versa)
• An array that had 10 items now has 0 (empty result set)
• A status field changed from "active" to "disabled"
• Extra fields appeared in the response (API version change)
• Error message text changed between environments

Real-World Use Cases

Replay comparison — You captured a request that returns incorrect data. You replay it using the Request Composer and compare the original with the replay. If the response changed, the server behavior is inconsistent or time-dependent. If it’s identical, the issue is reproducible.

Environment debugging — The same API call works in staging but fails in production. Compare the two flows to find the header, cookie, or body difference that causes the failure.

Before/after deploy — Compare flows captured before and after a deployment to verify the API response structure hasn’t changed unexpectedly (regression detection).

Auth investigation — Compare a successful login flow with a failed one. The request body diff shows what credentials differ; the response header diff shows whether different tokens or cookies were set.

A/B testing verification — Compare flows from two different user sessions to confirm that A/B test variants are serving different content as expected.