Disclaimer: This project is vibe coded. It works, but may contain questionable choices.
A single-file HTTP request timeline visualizer. Drop in a HAR or JSON file and get an interactive waterfall chart of your HTTP traffic — no server, no dependencies, no install.
- Download or clone this repository
- Open
index.htmlin any modern browser - Drop a HAR or JSON file onto the page (or click 'Select File' to browse)
That's it. Everything runs client-side in a single HTML file.
Note: The single-file approach is intentional. No build step, no dependencies, no npm install — just drop the HTML file anywhere and it works. Sometimes the simplest solution is the best one.
- Waterfall timeline — visualize request timing with start, response, and end markers
- HAR support — load
.harfiles exported from Chrome DevTools, Firefox, or any HAR-compliant tool - JSON support — use a simple JSON array/object format for custom instrumentation
- Request details — click any request to inspect headers, body content, and timing
- Body viewer — view request/response bodies as RAW, JSON, XML, HTML, Image, or HEX
- Thread grouping — see which requests ran on which threads
- Multi-select — click, Ctrl+click, Shift+click, or Ctrl+A to select rows
- Zoom — zoom into selections, scroll to zoom, or use the slider; zoom-to-fit button
- Content type detection — automatic type column (JSON, XML, HTML, IMG, JS, CSS, etc.)
- Drag & drop — drop files directly onto the page
- Zero dependencies — single HTML file, no build step, no server required
- Dark theme — easy on the eyes
- Export Fiddler Rules — export requests as Fiddler AutoResponder rules (.farx) with configurable match/response options; export all filtered or only selected requests
| Action | Shortcut |
|---|---|
| Select row | Click |
| Toggle selection | Ctrl+Click |
| Range select | Shift+Click |
| Select all | Ctrl+A |
| Horizontal scroll | Shift+Scroll |
| Zoom in/out | + / - |
| Open request details | Click request ID |
Standard .har files as exported from browser DevTools. See the HAR 1.2 spec.
See the samples/har/ folder for example HAR files.
The custom JSON format is designed to be lightweight and easy to generate and parse, with support for both inline content and external file references.
It is simplier than HAR allowing for easier generation and integration with non-standard tools that do not export HAR (you do not have to implement the full HAR spec.).
See the samples/custom/ folder for example JSON files.
A JSON array of request objects:
[
{
"id": 1,
"uri": "http://localhost:3000/api/users",
"method": "GET",
"statusCode": 200,
"statusMessage": "OK",
"startRequestTimestamp": 1704067200000,
"beginResponseTimestamp": 1704067200150,
"endResponseTimestamp": 1704067200200,
"threadId": "main",
"requestHeaders": "Content-Type: application/json\nAuthorization: Bearer ...",
"responseHeaders": "Content-Type: application/json\nContent-Length: 512",
"requestBodyChunks": ["{ \"name\": \"Alice\" }"],
"responseBodyChunks": ["{ \"id\": 1, \"name\": \"Alice\" }"],
"requestBodyPath": "req_body_1.json",
"responseBodyPath": "res_body_1.json"
}
]JSON Object:
Wraps the array in an object with an optional base path for body files:
{
"requests_data_path": "C:/data/connections/",
"requests": [
{ "id": 1, "uri": "http://localhost:3000/api/users", "..." : "..." }
]
}| Field | Description |
|---|---|
id |
Unique request identifier |
uri |
Request URL |
method |
HTTP method (GET, POST, etc.) |
statusCode |
HTTP response status code |
statusMessage |
HTTP response status text (e.g. "OK") |
startRequestTimestamp |
Request start time (epoch ms) |
beginResponseTimestamp |
First response byte time (epoch ms) |
endResponseTimestamp |
Response complete time (epoch ms) |
threadId |
Thread or connection identifier |
requestHeaders |
Request headers as a newline-separated string |
responseHeaders |
Response headers as a newline-separated string |
requestBodyChunks |
Array of strings containing the request body |
responseBodyChunks |
Array of strings containing the response body |
requestBodyPath |
File path to the request body content |
responseBodyPath |
File path to the response body content |
Note:
requestBodyPath/responseBodyPathandrequestBodyChunks[]/responseBodyChunks[]are interchangeable. Chunks contain the actual body content inline. Paths are links to external files, useful for saving memory when bodies are large. When using paths, setrequests_data_pathin the object format to provide the base directory.


