## TL;DR

A crash cuts the zip mid-write, but the trace data written before the crash is usually intact inside the partial archive. Repair the zip structure with a recovery tool, extract the raw trace files, and open the extracted folder directly. You lose the tail of the run, but everything before the crash stays readable.

## Error

```text
playwright trace.zip corrupted after browser crash: how to open
```

npx playwright show-trace trace.zip fails with a zip error (bad central directory or unexpected end of file).

## Steps

1. Try the normal open first and capture the exact error: npx playwright show-trace trace.zip. Expected output: a specific corruption error rather than a vague failure.
2. Attempt zip repair with zip -FF trace.zip writing to a new file, or extract what 7z can salvage. Expected output: a repaired archive, possibly with a warning about the truncated tail.
3. If repair fails, extract raw: unzip the partial file ignoring errors and copy out trace.trace, trace.network, and the resources folder. Expected output: the individual trace files on disk even though the zip wrapper is broken.
4. Open the extracted directory with npx playwright show-trace pointed at the folder path. Expected output: the trace viewer loads actions and screenshots up to the crash point.
5. For the next run, enable tracing with screenshots and snapshots so a future crash still leaves per-action artifacts. Expected output: a config change that makes the next crash less costly.

## When to use

- show-trace errors on a trace.zip from a crashed run.
- The trace viewer loads but stops mid-run.
- You need the network log from before the crash.

## When not to use

- No trace file was written at all (enable tracing first).
- The trace opens fine but is empty (the test produced no actions).
- The corruption is in a manually zipped archive (re-zip it properly).

## Variant phrasings

### Trace viewer blank after crash

The viewer needs trace.trace at minimum; if only resources survived, browse the screenshots folder directly.

### Missing resources in partial trace

Resource files for the last actions are the first casualty of truncation; earlier actions usually keep theirs.

### Screenshot-only recovery

With screenshots enabled, the resources folder holds a PNG per action; you can reconstruct the failure sequence without the viewer.

## Why it happens

Playwright streams trace events into the zip as the run progresses and only writes the zip central directory at the end. A browser crash kills the process before that final write, so the archive wrapper is broken while the already-written event data inside it is fine.

## Edge cases

- Repair tools can produce a zip that opens but silently drops the last few actions; treat the tail as unreliable.
- Very large traces (video enabled) corrupt more often on crash; consider screenshots-only tracing for crash-prone suites.
- If the crash also killed the Node process, the trace file may be zero bytes; check file size before attempting repair.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_a3LTTk1mOJWoRIKbIt9Q_A