Screenshots, Videos & Traces

page.screenshot() returns a PNG Buffer and, when path is given, also writes a file whose extension selects the format. locator.screenshot() captures one element. The full list of options for Playwright 1.64 is:

WebP support for page.screenshot() and locator.screenshot() arrived in Playwright 1.62, together with WebP snapshots for toHaveScreenshot. The next test takes the same page in every variant and prints the file sizes:

Source: Playwright: Screenshots

It passed, and printed:

The full-page image is larger than the viewport one because the 24 books fill more than 720 pixels; the lossy WebP at quality 60 is about a third of the PNG of the same page and about half of the JPEG. retina.png equals viewport.png because the headless Chromium device pixel ratio is 1; on a Retina screen (or with deviceScaleFactor: 2) scale: 'css' is what keeps the images at one pixel per CSS pixel. The default for the screenshot Playwright Test option, by contrast, is off; the screenshots above were requested explicitly, not by configuration.

The three use options choose when an artifact is kept. screenshot accepts off, on, only-on-failure and on-first-failure, or an object with mode, fullPage and omitBackground. video and trace accept the same, richer set of modes (video gained the full set in Playwright 1.61):

retain-on-failure pays the recording cost on every run in exchange for evidence of the first failure even without retries; on-first-retry pays it only when a test already failed once, but then has nothing from the original failure. A suite with retries: 2 in CI and on-first-retry is the common compromise.

Running the deliberately failing test from the folder tests/failing:

Source: Playwright: Test use options

with SHOW_FAILURES=1 npx playwright test failing failed in 3 seconds and wrote four files, all listed as attachments in the terminal output:

test-failed-1.png is the screenshot (full page, as configured), video.webm and trace.zip are the film and the trace (600 KB and 190 KB here). error-context.md is a Markdown file for people and AI assistants: the test name, the error with its call log, an accessibility-tree snapshot of the page at the failure (heading "The Quiet Compiler" [level=3] here) and the test source with an arrow at the failing line. Its first lines tell the reader to explain the failure concisely, so the file can be pasted into a chat as is. With RETRIES=1 the second attempt wrote the same four files in a sibling folder with the suffix -retry1; with retain-on-failure both attempts failed, so both were kept.

Playwright videos are WebM files, one per page, finished when the page’s browser context closes. The video size defaults to the viewport scaled down to fit 800 by 800 (800 by 450 if the viewport is not configured), and each page is scaled to fit inside the video. The video option takes an object with these fields:

Outside the test runner, pass recordVideo: { dir, size } to browser.newContext() and read the path from page.video().path() after the context is closed. In Playwright Test, attach the path of page.video() to a report or read it in a fixture after await context.close().

Since Playwright 1.59 page.screencast records a video, or streams frames, with explicit start and stop calls, independent of the video option. It also draws chapters and overlays, which makes it the tool for narrated demo recordings and for agents that need a "video receipt" of what they did:

Source: Playwright: Screencast

Both tests passed. The first printed narrated.webm 656712 bytes (a 30 fps film with the action highlights and the chapter card) and the second frames: true, last frame 77973 bytes, 1280x720. The second shows the rule in the documentation: when a screencast is already running (here the runner’s own video and trace screencast), the existing configuration takes precedence, so the requested 640 by 360 was ignored and the frames came at the page’s viewport size. showActions() and showChapter() also return disposables, and showOverlay(html) adds arbitrary HTML on top of the page until it is disposed or its duration ends. fps applies only together with path.

A trace is a zip file with, for every action, a before and an after DOM snapshot, the action’s locator and call log, screenshots for a filmstrip, console messages and network requests, and the test source. The trace option takes the same modes as video or an object that selects what is recorded: screenshots (the filmstrip, default true), snapshots (DOM and, with { dom, aria, screen }, accessibility-tree and screen captures per action), sources (copy the test files into the trace) and attachments (include testInfo.attach() files, default true). Open one with npx playwright show-trace trace.zip, drop it on https://trace.playwright.dev (loaded entirely in the browser, nothing is uploaded), or read it from the command line; the viewer’s panels are described in Playwright: Debugging, Tracing & Codegen. The command line was run on the trace of the failing test above:

Source: Playwright: Trace viewer

actions listed Before Hooks, the fixtures that launched the browser, Navigate /books, Fill "quiet", Click and the failing assertion with the duration of each; attachments listed screenshot (image/png), video (video/webm) and error-context (text/markdown), so the video and the screenshot are also inside the trace.

When you drive Playwright without the test configuration, or want several trace files from one context, use context.tracing. Inside Playwright Test the runner already traces the contexts of its fixtures, and calling tracing.start() on them fails with "Tracing has been already started"; the test below turns the configured tracing and video off for its file first:

Source: Playwright: Tracing

It passed and printed load.zip true | interaction.zip true | video true. Two details were learned the hard way: test.use() for trace and video must be at the top of the file (inside a describe Playwright throws, because those options force a new worker), and a stop() after a stopChunk() without an open chunk fails with "Must start tracing before stopping", so the last chunk is closed with stop({ path }). The live option (since 1.59) writes the trace to an unarchived file as the run progresses, which is what lets a viewer follow a long test while it runs.

testInfo.attach(name, { body | path, contentType }) adds any value or file to the test result; reporters decide how to show it. The HTML reporter lists attachments under each test, with screenshots, videos and traces as viewable items, and the trace viewer’s Attachments tab shows them as well (including the actual, expected and diff images of visual comparisons).

Source: Playwright: TestInfo.attach

It passed and printed book page (image/png), url (text/plain). attach copies a path into a location the reporters can read, so the original can be deleted straight after the call. Use body for in-memory data and give the right contentType, since a Buffer without one is stored as application/octet-stream. npx playwright show-report opens the HTML report that the configuration above wrote to playwright-report.

The other bindings expose the same options with their own naming. They are listed for reference; the screenshots, video and tracing calls below were not run in those languages (the bindings were exercised for other topics in Playwright with Python, Java and .NET).

The pytest plugin has the CLI options --screenshot only-on-failure, --video retain-on-failure and --tracing retain-on-failure for the same modes.

When a test fails during cypress run, Cypress takes a screenshot automatically; screenshotOnRunFailure: false (in the configuration or in Cypress.Screenshot.defaults()) turns that off. A failure screenshot is always taken with capture: 'runner' (the whole browser window, including the Command Log when the Runner UI is shown). With Test Replay enabled and the Runner UI hidden, the runner capture shows the application only. For explicit screenshots, cy.screenshot([fileName][, options]) takes these options, which Cypress.Screenshot.defaults() sets for all calls:

Source: Cypress: screenshot

Together with this failing test:

Source: Cypress: Screenshots and Videos

npx cypress run --browser chrome (Chrome 155, headless) ran both specs; the after:screenshot handler printed one line per file, and the two attempts of the failing test (one retry configured) each produced a failure screenshot:

The naming follows {screenshotsFolder}/{spec path}/{suite -- test name}.png for unnamed screenshots ({name}.png for named ones, with folders created from slashes), a (failed) suffix for failures, (attempt n) for retries and a (1), (2) numeric suffix for duplicates unless overwrite is set. The screenshot is not the size of viewportHeight: the headless window and the Runner layout decide, and the heights above (633) differ from the configured 720, so check the size in your own environment before comparing images. Electron (now a deprecated test browser) produced images at twice the size (2560 by 1440) on this Retina host, whereas Chrome produced 1280 wide ones, which is a good reason to take evidence in the browser CI will use. The runner capture matched the viewport one because the Runner UI is hidden in cypress run.

A screenshot takes about 100 ms and is asynchronous, so the page may have changed by the time it is taken; this is most visible in the automatic failure screenshot, which is taken after the failing command has timed out. A named screenshot taken just before the assertion that fails is often more telling than the failure screenshot.

video: true makes cypress run record one MP4 per spec (the default is false since Cypress 13). After recording, Cypress encodes the file: videoCompression is false by default, which skips compression (a bigger file, faster), true means Constant Rate Factor 32, and a number sets the CRF itself (lower is larger and better; try a higher number on slow virtual machines). The embedded chapter markers, one per test attempt, are written only when compression is on. On this run the compressed video of the failing spec was 64 KB. Because the video of a passing spec is rarely wanted, the after:spec handler in the configuration above deletes it; the summary table then printed Video: false for that spec, and a run with the delete line disabled printed Video: true and left screenshots.cy.ts.mp4 on disk, so the handler is what decides. The handler also decides what gets uploaded to Cypress Cloud, because a deleted video is never uploaded. The results object passed to after:spec contains video, screenshots and each test’s attempts, which is how it finds specs that needed a retry. The full list of node events, including after:screenshot (which can rename or move a file by returning { path }), is in the debugging page.

Test Replay, a feature of Cypress Cloud, is Cypress’s answer to traces: when a run is recorded (cypress run --record), the Cloud stores everything needed to re-open the test at any point in time with the Command Log, the DOM, network requests, console messages, JavaScript errors and element rendering, in the browser, with no reproduction on a developer machine. It is available on all Cloud plans within usage limits, and the Cypress documentation presents it as a replacement for video as the CI debugging artifact. Recording requires an account and a record key, so Test Replay was not run for this page; the Cloud page shows what the terminal prints and what was recorded without an account.

The W3C commands are Take Screenshot, Take Element Screenshot and Print Page. In Java, TakesScreenshot.getScreenshotAs() returns a File, byte[] or Base64 String according to the OutputType; the Chrome, Firefox, Edge and Remote drivers all implement it. WebElement is a TakesScreenshot too. In Python the methods are save_screenshot(path) (alias get_screenshot_as_file), get_screenshot_as_png() and get_screenshot_as_base64(), and element.screenshot(path). PrintsPage.print(PrintOptions) and Python’s driver.print_page(print_options) return a Base64 PDF; the options cover orientation, page range, size, margins, scale, background and shrink-to-fit. The Java test, and the base class and extension it uses, are in the next sections; the first test takes all four captures:

Source: Selenium: Windows and tabs (TakeScreenshot, TakeElementScreenshot)

It passed in headless Chrome 155 and printed viewport.png 52444 bytes, base64 69928 chars, count.png 2509 bytes, catalogue.pdf 174380 bytes (%PDF-); the Base64 text is a third longer than the PNG it encodes. The Python equivalent:

Source: Selenium: Print Page

It passed with a 154 KB PDF. Printing was tried only in headless Chrome; the print command is part of the W3C standard, but which browsers implement it and how they lay the page out differs, so inspect the PDF of the browsers you use.

The classic W3C screenshot is of the viewport. Two ways to get the whole page:

Source: Selenium: BiDirectional API (W3C compliant): Browsing Context

It passed and printed bidi viewport 52444 bytes, bidi document 89778 bytes. The Python call is driver.browsing_context.capture_screenshot(context=context, origin="document"), which printed bidi viewport 52444 bytes, bidi document 89759 bytes in the same project. The local-driver Firefox command was not run, because Firefox does not start on the host used here; Java was run against Firefox 158 in a container instead:

Source: Selenium: Firefox, full page screenshots

The cast to HasFullPageScreenshot works because the remote builder returns an augmented driver. It passed against the Grid below and printed firefox viewport 85028 bytes, full page 107578 bytes.

Selenium has no automatic capture, so the test framework’s lifecycle does it. The hook must run before the browser is closed. In JUnit 5, TestWatcher.testFailed() is called only after the @AfterEach methods, so a watcher that takes the screenshot finds the session gone: the run below printed TestWatcher could not screenshot: NoSuchSessionException. An AfterTestExecutionCallback, which runs right after the test method and before @AfterEach, still has the driver:

Source: JUnit 5: Lifecycle callbacks

The test base class declares @ExtendWith(ScreenshotOnFailure.class) and implements the small HasDriver interface (WebDriver driver();) so the extension can reach the driver. Running FailingTest, which asserts a title that does not exist, printed failure screenshot: target/evidence/FailingTest-failsOnPurpose.png (52444 bytes). In pytest the same job is done in a fixture, but the test outcome is not visible to fixtures by default; a hook wrapper stores each phase’s report on the test item:

Source: pytest: Making test result information available in fixtures

With pytest 8 or later (the wrapper=True hook style) the failing test left evidence/test_fails_on_purpose.png (52444 bytes) while the two passing tests left none. Extend the hook with driver.page_source or the browser log (driver.get_log("browser") in Chromium) when a picture is not enough; Selenium has no trace to attach.

Video recording belongs to the Grid, not to the driver. The selenium/video image runs ffmpeg against the virtual display of one browser Node container (so the browser must run headed) and writes MP4 files to /videos. The Compose file below starts a Hub, a Firefox Node limited to one session, and one recorder for it; SE_NODE_MAX_SESSIONS=1 matters because a recorder films one display, and SE_VIDEO_FILE_NAME=auto names the file after the se:name capability and the session id:

Source: docker-selenium: Video recording

With the Java test from the previous section (which sets se:name and se:recordVideo) it produced fullPageScreenshotAndRecordedSession_2e443aa2-7c00-400b-a2ac-cea7439a5a37.mp4, 160 KB, a valid MP4 (ftyp header). A single-container attempt, standalone-firefox plus a recorder, did not record: the recorder polled the Node status endpoint on port 5555, which a standalone container does not serve, and pointing it at port 4444 let it connect but produced no file, so use the Hub and Node layout above. The recorder polls for sessions, so sessions shorter than about a second may not be filmed; the test above keeps the session open for six seconds. Details such as the event-driven mode, upload of finished videos and the Dynamic Grid’s --docker-video-image are in Selenium Grid. Cloud grids (BrowserStack, Sauce Labs, TestMu AI) record video and screenshots on their side and expose them through their dashboards; those services were not run for this page.