tracelane vs Playwright Trace Viewer

Both capture what the browser did during a failed Playwright test. The delta is format, consumer, and what you can do with the artifact.

Playwright ships a built-in trace viewer. If you're already using Playwright, “why not just use that?” is a fair question. This page is the honest answer — including the cases where the built-in tool is the right choice.

At a glance

	tracelane	Playwright Trace Viewer
Output format	A single self-contained `.html` file. Player, rrweb event blob, console panel, and failed-network panel all inlined — opens in any browser offline.	A `trace.zip` archive. Contains DOM snapshots, screenshots, network HAR, and test-step metadata in a binary format.
How to view it	Double-click. Any browser, any machine, no tooling, no internet.	`npx playwright show-trace trace.zip`, or drag-drop to trace.playwright.dev. Requires Playwright CLI or an internet connection to the hosted viewer.
Generates a Playwright repro	Yes. `generate_playwright_repro` turns the recorded session (real user actions + console + network) into a runnable Playwright test. The agent can re-run it to verify a fix worked — not just review what broke.	No. The trace is a record of what happened; it does not emit a test from the recording.
AI-agent readable	Structurally, via MCP: `get_session_console_errors`, `get_session_network_errors`, `get_dom_snapshot`, `get_user_action_before_error`. The agent asks, gets JSON, acts.	Not natively. The `trace.zip` binary format requires tooling to parse. trace.playwright.dev has no MCP surface.
Security-hygiene signals	Surfaces advisory, OWASP-aligned hygiene signals — missing security headers, insecure cookies, mixed content, reverse tabnabbing — right in the failed-test report and in the Copy-as-Markdown-for-AI output. Advisory, not a scanner.	No. The trace records what the test did; it does not flag security-hygiene issues.
Runner support	WebdriverIO (service) and Playwright (reporter + fixture) today. Cypress on the roadmap.	Playwright only.
Sharing	Attach the `.html` file to a Jira ticket, Slack message, email, GitHub issue. No account needed to view.	Attach the `trace.zip` + instruct the recipient to run `npx playwright show-trace`, or upload to `trace.playwright.dev` (public URL, accessible to anyone with the link).
Air-gapped CI	Works. The artifact is a plain file.	Self-hosting `npx playwright show-trace` works; the trace.playwright.dev hosted viewer requires outbound internet.
Step-by-step test breakdown	No. tracelane records the rrweb DOM stream + console + network; it has no knowledge of Playwright test steps, fixtures, or assertion names.	Yes — the trace viewer is tightly integrated with Playwright's test model. Every step, fixture setup, assertion, and retry is a named node in the timeline.
Screenshots	DOM reconstruction (rrweb). Not pixel screenshots — the DOM is re-rendered live in the player, so you can hover and inspect elements at any frame.	Both pixel screenshots and a scrubbable DOM viewer. Playwright captures full screenshots at key steps in addition to snapshots.
Network capture	Failed/notable responses (`status ≥ 400`) captured in-page on every browser, in-timeline alongside DOM events; on Chromium CDP additionally supplies authoritative status + no-response failures.	Full HAR (all requests), tightly tied to the step timeline.
Cost	Free. Apache 2.0.	Free. Part of Playwright (Apache 2.0).
Maturity	Pre-1.0 (alpha as of 2026). Active development.	Mature, part of Playwright core since v1.14 (2021).

When tracelane is the right choice

You want to turn the failure into a runnable Playwright repro an AI agent can replay to verify a fix — not just review what broke.
The person reviewing the failure doesn't have Playwright CLI installed (PM, QA, contractor, non-dev reviewer). The .html file opens anywhere.
You use WebdriverIO (the Playwright Trace Viewer is Playwright-only).
You want your AI coding agent to query the session structurally over MCP rather than parse a binary trace format.
You want the artifact to live as a file in Jira, S3, or your existing CI log store — no tooling chain to open it.
Air-gapped CI or a compliance policy against uploading traces to a third-party web viewer.

When Playwright Trace Viewer is the right choice

You want step-by-step Playwright test introspection: named fixtures, before/afterAll hooks, retry counts, per-step timing, assertion text. The trace viewer knows your test model; tracelane sees only the browser stream.
You want full network HAR across all requests (not just failures) correlated to the test step that triggered each one.
Pixel-accurate screenshots at each step matter — for visual regression debugging, the step-level screenshot capture is more precise than rrweb DOM reconstruction.
Your team already lives in the Playwright ecosystem and the trace.zip workflow (attach artifact, show-trace) is established.

Can you use both?

Yes — they are not mutually exclusive. Configure Playwright to emit both trace: 'on-first-retry' (for the detailed step-level trace) and the tracelane reporter (for the self-contained HTML + repro generation). Each artifact serves a different job: the trace for deep step debugging, the tracelane report for sharing and AI-agent consumption.

Why this page exists

Comparison pages capture search intent that official docs don't address (“playwright trace viewer alternative”, “playwright trace viewer vs”, “self-contained playwright test report”). The table above is the honest answer to “should I use tracelane or just turn on tracing?” — and the honest answer is “it depends what you want to do with the artifact.”

Found something inaccurate above? Open a PR on this page — the goal is accuracy, not advocacy.