Building with AI, keeping it human

I keep ending up with HAR files that feel too heavy to open and too awkward to query. I wanted a workflow where network traces become something I can ask real questions of without writing one-off jq scripts.

Harlite turns HAR into a queryable SQLite database so you can explore web traffic with SQL.

If you live in developer tools or work on APIs, that shift matters. You go from file spelunking to repeatable analysis, and you can hand the database to teammates or to an AI agent without having to teach a custom query language.

HAR files are great raw material and a painful interface

A HAR capture is a gold mine for debugging, perf work, and forensics. It also ships as a JSON blob with nested arrays, binary bodies, and inconsistent shapes depending on the browser. You can absolutely use jq, but once you have more than a handful of questions, the cost is the script, not the data.

Harlite accepts that the HAR format is the input, not the interface. It imports the data into a stable schema, normalizes common fields, and leaves you with a database you can query from anywhere.

The workflow is import once, then SQL everywhere

The core loop looks like this:

harlite import session.har

harlite query "SELECT url, status FROM entries WHERE status >= 400"

That database is plain SQLite. Use sqlite3, Datasette, DBeaver, Python, whatever you already like. If you want to automate, the CLI has commands like harlite stats, harlite info, and harlite export for predictable outputs.

Bodies are optional, deduped, and fast enough to be practical

I wanted it to be useful for quick questions without hauling giant blobs around. By default, harlite imports metadata only. When you do need bodies, you can opt in with flags and limit size. It also deduplicates bodies by BLAKE3 hash, so a repeated JS bundle is stored once even if it appears across dozens of entries.

There are a few modes depending on how heavy you want to go:

• Store text bodies under a size threshold for fast analysis.
• Decompress gzip or br on import so you can search decoded content.
• Extract bodies to disk so the database stays slim, while keeping hash references.

SQLite FTS5 is wired in when bodies are present, so you can do text searches across responses without inventing another index.

The schema makes the common questions simple

Entries track the things you usually care about: method, URL, host, status, timings, headers, and body hashes. Headers are stored as JSON so you can filter with SQLite JSON functions. That means you can slice by host, status, or path quickly, and then use JSON queries when you need the weird edge case.

Here is the kind of query I run constantly:

SELECT method, url, status, time_ms
FROM entries
WHERE time_ms > 1000
ORDER BY time_ms DESC;

Or when I am digging through APIs:

SELECT method, host, path, status
FROM entries
WHERE path LIKE '%/api/%'
ORDER BY started_at;

Harlite fits naturally into AI agent workflows

Agents already speak SQL. So when I want an assistant to help me triage a HAR, I can say, query this database for all POSTs with a 400+, or find the biggest responses from a specific host. That is a small difference that saves real time and avoids explaining bespoke filters over and over.

Example use cases that feel real

I built harlite because I kept needing the same answers:

• Identify slow or failing endpoints after a refactor.
• Extract all JSON responses from a specific API domain.
• Compare traffic across multiple HAR captures in one database.
• Spot redundant requests by finding duplicate response hashes.
• Hand a compact database to a teammate or agent for fast analysis.

If any of that sounds familiar, harlite is probably worth a look.

Getting it running today

It is open source, MIT licensed, and available on crates.io. Install with cargo, or build from source if you want to hack. The README calls out a current requirement of Rust 1.85 because of edition 2024 dependencies, so assume stable and up to date.

cargo install harlite