Download flows are deceptively simple in product demos and surprisingly messy in real test suites. A receipt button does not just click and vanish. A CSV export may arrive with the wrong delimiter, a malformed UTF-8 BOM, stale data, or a filename that changes by locale. A PDF receipt may download correctly but contain the wrong order number, the wrong totals, or an empty page because the rendering service failed in a way the browser cannot see.

That is why downloadable receipt testing and CSV export testing deserve their own evaluation criteria. The key question is not which framework can click a button. It is which one gives you reliable control over the download event, a clean path to inspect the file, and enough browser state to validate what the user actually received after the browser hands off the file.

This article compares Playwright and Selenium for downloadable export testing, with a practical lens on file validation after download, post-export assertions, and the maintenance cost of keeping these tests stable.

What export validation actually needs to prove

A good export test usually has four layers of validation:

  1. The export action is reachable and enabled for the right user.
  2. The browser initiates a download, or the app returns a file response.
  3. The file is persisted or captured in a test-accessible location.
  4. The file contents match the expected business data.

That fourth step is where many tests get weak. Teams often stop after asserting that a file exists, but existence only proves the browser did something. It does not prove the export is correct.

For receipts, you often need to validate:

  • filename pattern or extension
  • PDF text content, if the receipt is a PDF
  • order ID, date, customer name, totals, and tax amounts
  • locale-specific formatting
  • whether the file is actually readable and not corrupted

For CSV exports, you usually need to validate:

  • delimiter and quoting rules
  • column order and headers
  • row count and content
  • date and currency serialization
  • encoding, especially UTF-8 versus UTF-8 with BOM
  • export filters, pagination, and sort order

A download test that only checks “file exists” is useful, but only as a smoke check. It is not a strong export validation strategy.

The core difference: how much control you get after the click

Playwright and Selenium both automate browsers, but they differ sharply in how much native help they provide for file downloads.

Playwright: first-class download handling

Playwright treats downloads as a first-class concept. You can wait for a download event, save the file to a known path, inspect the temporary file, and make assertions against it without much ceremony. The official API is designed around this workflow, which makes it easier to write deterministic download tests.

A typical Playwright pattern looks like this:

import { test, expect } from '@playwright/test';
import fs from 'node:fs';

test(‘exports csv and validates content’, async ({ page }) => { await page.goto(‘https://app.example.com/reports’);

const downloadPromise = page.waitForEvent(‘download’); await page.getByRole(‘button’, { name: ‘Export CSV’ }).click();

const download = await downloadPromise; const path = await download.path(); expect(path).not.toBeNull();

const content = fs.readFileSync(path!, ‘utf8’); expect(content).toContain(‘order_id’); expect(content).toContain(‘12345’); });

This is attractive because the test keeps the browser interaction and file inspection in one flow. You can also work with download.saveAs(...) if you want to preserve the file across the test run.

Selenium: possible, but more plumbing

Selenium can absolutely test downloads, but it usually requires more environment setup and more framework code. The browser may download directly to disk, and your test needs to know where that disk location is, how to wait for the download to complete, and how to handle browser-specific settings.

A common Selenium approach in Python looks like this:

import os
import time
from selenium import webdriver
from selenium.webdriver.common.by import By

options = webdriver.ChromeOptions() options.add_experimental_option(“prefs”, { “download.default_directory”: “/tmp/downloads”, “download.prompt_for_download”: False, “safebrowsing.enabled”: True, })

driver = webdriver.Chrome(options=options) driver.get(“https://app.example.com/reports”) driver.find_element(By.CSS_SELECTOR, “button.export-csv”).click()

expected_path = “/tmp/downloads/report.csv” for _ in range(20): if os.path.exists(expected_path) and not expected_path.endswith(“.crdownload”): break time.sleep(1)

with open(expected_path, encoding=”utf-8”) as f: content = f.read() assert “order_id” in content

This works, but note the extra burden. You need download preferences, directory handling, file completion polling, and browser-specific behavior. In a local run that may feel manageable. In CI, with parallelism and ephemeral containers, the setup becomes a major source of failure.

Download interception versus file-system polling

When comparing Playwright vs Selenium downloadable export testing, the most important distinction is not just convenience. It is the reliability of the observation point.

Playwright observes the download event directly

Playwright can wait on a download event produced by the page. That means the test does not have to guess when the file is done. It receives the browser event and then inspects the captured file.

This reduces a common failure mode in export tests, where the test checks the filesystem too early and reads a partial file or a temporary extension like .crdownload.

Selenium often relies on the browser writing to disk

Selenium generally expects the browser to manage downloads and the test to watch the file system. This is workable, but it is inherently more timing-sensitive. The test must understand browser download semantics, platform-specific temp file behavior, and sometimes remote grid limitations.

That does not make Selenium unsuitable. It means the team must be explicit about the environment. If your CI workers run headless browsers in containers, file paths and permissions need to be standardized. If you run browser tests on a remote grid, local disk access may not even be available in the same way.

Validation after download, not just after click

The phrase “post-export validation” matters because a click test and a file test are different things.

A click test answers: did the control trigger something? A file test answers: did the right artifact arrive, and does it contain the right data?

That distinction leads to better assertions.

For CSV exports

At minimum, parse the CSV rather than search for raw strings if the content matters. String matching can hide quoting issues, delimiter errors, or row misalignment.

In Playwright, you can read the file and use a parser like csv-parse or a built-in strategy suitable for your stack.

import fs from 'node:fs';
import { parse } from 'csv-parse/sync';

const content = fs.readFileSync(path!, ‘utf8’); const records = parse(content, { columns: true, skip_empty_lines: true });

expect(records).toHaveLength(3); expect(records[0].order_id).toBe(‘12345’);

This is stronger than matching a single substring because it validates structure. It also helps surface errors like duplicate headers or rows shifted into the wrong columns.

For receipt PDFs

PDF validation is trickier. If the receipt is a PDF, you may need a PDF text extraction library or a document comparison strategy. The browser alone does not tell you whether the file content is correct.

A useful structure is:

  • confirm the download completed
  • confirm the file extension is expected
  • confirm the file is readable by a PDF parser
  • extract text and validate key fields
  • optionally validate metadata or page count if the document format is stable

If your application generates PDFs server-side, a separate API-level validation of the generation endpoint may sometimes be more stable than browser-driven verification. The browser test still has value because it proves the front end and auth flow can trigger the download, but the content check may be easier to maintain at the service boundary.

Typical failure modes in export testing

Export flows fail in ways that are easy to miss during casual testing.

1. The filename is right, the contents are wrong

This happens when the UI passes stale query parameters, an old filter state, or an incorrect tenant ID. The browser download still succeeds, but the file contains the wrong dataset.

2. The file exists, but it is incomplete

Especially in Selenium-style filesystem polling, the test may read the file too early. The result can be truncated CSV rows or unreadable PDFs.

3. The export varies by locale

Dates, decimal separators, and encodings can differ across environments. Export tests should account for locale explicitly, or pin the app to the relevant locale in the test setup.

4. The export control is visible but not actually usable

Role-based access, feature flags, or backend permission checks may disable the export only for certain users. Tests should cover both positive and negative access cases.

5. The browser downloads the file, but the environment cannot store it

This is common in CI when directories are read-only, ephemeral, or misconfigured for headless execution.

A download test is only as trustworthy as the path between the browser event and the file parser.

Playwright strengths for export validation

Playwright is usually the stronger choice when your team wants fine-grained, code-based export testing.

Why it fits well

  • Download events are built into the API.
  • The same test can validate UI state and file content.
  • Headless and CI behavior tends to be easier to control.
  • Locators and waiting primitives are designed for browser synchronization, which helps when export buttons appear after async rendering.
  • The test code is concise enough that reviewers can understand what is being checked.

Where Playwright still needs discipline

Playwright does not remove the need for careful test design. The common maintenance risks are:

  • over-testing the same export through too many UI permutations
  • conflating UI assertions with file-content assertions
  • writing brittle comparisons against entire file contents when only a few fields matter
  • ignoring parser errors and only checking string presence

Playwright is strongest when the team uses it to capture the file and then hands the file to a dedicated parser or validator.

Selenium strengths for export validation

Selenium remains relevant, especially when an organization already has a broad WebDriver investment.

Why teams still use it

  • existing browser coverage and mature language bindings
  • established CI infrastructure and page-object patterns
  • compatibility with a wide range of browsers and environments
  • easier reuse if the organization already standardized on WebDriver for most UI tests

The tradeoff

For downloadable export testing, Selenium usually requires more custom setup. That is not a flaw in the project, but it does raise total maintenance cost. Someone needs to own browser download preferences, path management, temp file cleanup, retry logic, and the logic that detects download completion.

If the team already has a strong Selenium suite, the right question is not whether Selenium can do this. It is whether the incremental complexity is worth it for each export scenario.

A practical decision matrix

Use these criteria to choose the framework for downloadable receipt and CSV export tests.

Choose Playwright when:

  • you want first-class download handling
  • the test suite needs reliable post-download assertions
  • you are building new UI automation from scratch
  • CI reliability matters more than preserving an older WebDriver pattern
  • your team values a shorter path from click to file validation

Choose Selenium when:

  • your organization already has deep Selenium investment
  • the export tests need to fit into an existing WebDriver architecture
  • your browser matrix or execution environment is already standardized around Selenium
  • the team is comfortable owning additional download plumbing

Reconsider browser-driven export tests entirely when:

  • the exported file is generated by a backend service with a stable API
  • the validation is mostly about document content, not UI behavior
  • the UI is already covered by separate integration tests
  • the download is slow enough that end-to-end tests become a bottleneck

In those cases, a direct API validation or service-level test may be a better fit, with a smaller browser check to ensure the button triggers the correct endpoint.

A layered testing strategy works better than one giant export test

The most durable export validation usually combines multiple layers:

  1. UI smoke check: the export button appears for the right user.
  2. Browser download check: clicking the button produces a file.
  3. File integrity check: the file opens or parses successfully.
  4. Content check: the data matches the expected transaction or report state.

This layered approach isolates failures. If the UI smoke test fails, you know the export control is missing. If the download event fails, the UI may be broken or the browser blocked the download. If the content check fails, the bug may be in backend report generation rather than the browser automation.

What to assert for different export types

Receipts

Receipts are usually narrow documents with high business importance. Useful assertions often include:

  • order or invoice number
  • customer name or masked email
  • payment total
  • tax line items
  • timestamp and timezone
  • branding or document title if legally relevant

If the document is legally sensitive, you may also need to validate that the right account or jurisdiction-specific footer appears.

CSV exports

For CSV, focus on structural correctness first:

  • column names
  • row count
  • sort order, if guaranteed
  • filter scope
  • encoding and delimiter
  • null or empty value serialization

Then validate critical data points rather than every cell unless the export is small and stable.

Zip or multi-file exports

If the app downloads a zip archive or a bundle of files, the test should verify archive integrity and inspect at least one representative file. This is where Selenium setup can get especially noisy, because the test must handle multiple file writes and completion conditions.

Where Endtest can fit for teams that want less plumbing

For teams that want export-flow coverage without building and maintaining as much framework code, Endtest can be a relevant alternative to evaluate. Its agentic AI approach and AI Assertions are aimed at reducing brittle selectors and letting teams express validations in more human-readable terms, which can help when the check is broader than a single DOM node or string match.

That does not make it a universal replacement for Playwright or Selenium. It does suggest a different maintenance profile. If your team is spending too much time on locator churn, self-healing behavior and platform-native assertions may reduce some of the overhead that commonly accumulates in custom browser automation.

A practical rule is simple: if download flows are a small part of a much larger code-first test architecture, keep using Playwright or Selenium. If maintaining export coverage is becoming a steady source of framework plumbing, it may be worth evaluating a lower-maintenance option and comparing the reviewability of its test steps with your current approach.

How to keep export tests stable in CI

A few operational details matter a lot more than the framework logo:

  • use a dedicated download directory per test worker
  • clean up files between runs
  • avoid shared paths in parallel execution
  • pin locale and timezone where content formatting matters
  • wait for the file to be fully written before parsing
  • keep the assertion scope narrow, especially for large documents
  • log the saved path when a download fails, so triage is faster

If your pipeline includes containerized browser runs, make sure the filesystem path is writable and the container has enough permissions to persist temporary files. For remote execution, confirm that the framework can still expose the downloaded artifact to the test process.

A GitHub Actions job might look like this at a high level:

name: export-tests
on: [push]

jobs: ui: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npx playwright test export.spec.ts

The exact setup will vary, but the principle is the same, keep download paths predictable and artifacts easy to inspect.

Bottom line

For downloadable receipts, CSV exports, and post-export validation, Playwright usually provides the cleaner path because download handling is built into the test model. That makes file assertions easier to write and easier to trust. Selenium can absolutely cover the same scenarios, but it typically requires more environment-specific plumbing and more care around file completion, paths, and CI behavior.

The better framework depends on your current stack and ownership model. If your team is starting new export coverage and wants a direct route from user action to file inspection, Playwright has a practical advantage. If you already have a Selenium ecosystem and the export tests are just one part of a larger investment, Selenium remains viable, provided you are willing to own the download mechanics.

The more important lesson is architectural: do not stop at “file downloaded.” Validate the artifact, validate the content, and choose the smallest layer of automation that gives you confidence in the export path without creating a maintenance burden that outgrows the feature itself.