DiagramPreview
Advanced previewNo AILocal previewExportDebugging

HAR File Viewer

Paste a HAR export and inspect request timing, status codes, hosts, MIME types, and slow calls in a readable waterfall preview.

Examples
Detected JSON

This input may work better in the matching tool. Open JSON tool

Waterfall analysisReady
Your HAR timeline will appear here.

Continue with a related tool

Move this preview into a nearby workflow for conversion, debugging, or export.

How to use

  1. 1Export a HAR file from browser DevTools after reproducing the issue.
  2. 2Paste a sanitized HAR sample and inspect request count, total time, failed calls, hosts, and slowest requests.
  3. 3Look for long waits, repeated calls, 4xx/5xx responses, large payloads, and third-party hosts.
  4. 4Share a screenshot or exported summary after removing cookies, tokens, and private headers.

Common use cases

Frontend performance debuggingAPI waterfall reviewIncident screenshotsThird-party request auditBrowser network export preview

FAQ

Can I paste a production HAR file safely?

Only after sanitizing it. HAR files can contain cookies, Authorization headers, URLs with tokens, and private request bodies.

What should I inspect first?

Start with failed requests, total page time, slowest requests, duplicate calls, and unexpected third-party hosts.

Is HAR Viewer enough for root-cause analysis?

It is a triage surface. Use traces, server logs, and browser performance profiles for deeper root-cause analysis.

HAR File Viewer previews browser network exports as request timelines, status summaries, slowest calls, host breakdowns, and waterfall-style debugging notes.

It helps frontend and API engineers inspect real browser behavior without opening a heavy desktop tool or pasting sensitive logs into an AI chat.

Use it to compare page loads, explain slow endpoints in issues, prepare incident screenshots, and decide which requests deserve deeper tracing.

Demo: turn a browser export into an API debugging note

A good HAR review captures the user action, then explains which request was slow or failed. The viewer helps reduce a raw JSON export into a few facts that belong in an issue.

  • Record only the failing workflow, not a full browsing session.
  • Remove cookies, Authorization, Set-Cookie, and private query parameters.
  • Compare status codes and timings before assuming the frontend is at fault.
1. Reproduce checkout submit
2. Export HAR from DevTools Network panel
3. Remove Cookie and Authorization headers
4. Inspect failed requests and slowest calls
5. Attach screenshot plus sanitized request IDs

This workflow creates a useful bug report without exposing the entire browser session.

Performance debugging: read HAR as a waterfall, not a table

A HAR file is most useful when it explains where time is spent. Sort and group requests by navigation phase, cache behavior, blocking time, and third-party domains instead of only scanning status codes.

  • Look for long queued or blocked times before blaming the backend.
  • Group third-party scripts and fonts to see their total page cost.
  • Compare transferred size with decoded size to catch compression and cache issues.
GET /app.js 200 42ms 18KB cached
GET /api/feed 200 840ms 74KB network
GET https://analytics.example/script.js 200 310ms 92KB third-party

Review checklist for HAR File Viewer

Use HAR File Viewer when you need to inspect source content visually before it becomes documentation, a pull request note, an incident write-up, or a handoff artifact. Preview HAR request timelines, status codes, slowest calls, and host breakdowns.

Before exporting, check that labels are readable, relationships match the source, generated examples do not contain private data, and the preview still makes sense after you edit the input.

Limits and troubleshooting

If the preview fails, reduce the input to the smallest complete example, confirm the format syntax, and then add sections back one at a time. Many rendering failures come from partial files, indentation mistakes, missing diagram headers, or copied snippets that depend on hidden context.

Treat the preview as a review surface rather than a source of truth. Generated diagrams, converted files, dashboards, and rule examples should be checked before they are used in production documentation or operations.

Example inputs to test

  • Checkout HAR: { "log": { "version": "1.2", "creator": { "name": "DiagramPreview" }, "entries": [ { "startedDateTime": "2026-06-16T10:00:00.000Z", "time": 82, "request": { "method": "GET", "url":...
  • Slow API: { "log": { "entries": [ { "time": 1280, "request": { "method": "GET", "url": "https://api.example.com/reports/monthly" }, "response": { "status": 200, "content": { "mimeType": "app...
  • Third-party assets: { "log": { "entries": [ { "time": 42, "request": { "method": "GET", "url": "https://cdn.example.com/app.css" }, "response": { "status": 200, "content": { "mimeType": "text/css" } }...

Tool maturity

Advanced preview

Advanced parser

This tool extracts useful structure and relationships from developer input. Complex edge cases should still be checked against the source.

The maturity label is not a quality score. It tells visitors whether the tool is best for stable export, deeper debugging, quick parsing, or AI-assisted generation.