Uploading Files to Hidden Input Elements

Almost every design system hides its <input type="file">. The native control cannot be styled, so teams set display: none, opacity: 0, or a one-pixel clipped box on the input and put a <label> or a <button> on top of it. The moment a test tries to click that pretty button, the browser opens an operating-system dialog no automation tool can reach, and the run stalls until the timeout fires. Playwright never needs that dialog: setInputFiles() writes file entries directly onto the input element, and the filechooser event intercepts the picker for inputs that only exist after a click. This page covers the three shapes hidden uploads take — a hidden input already in the DOM, an input created on demand, and a drop zone with no input at all — building on File Uploads & Downloads within Advanced Interactions & Test Assertions.

Root cause: the input is hidden on purpose and the picker is out of reach

The file input is the one form control browsers refuse to let CSS restyle, so component libraries hide it and delegate activation to a <label for="..."> or a JavaScript click forwarder. Hiding it has two consequences for tests. First, a hidden node is removed from the accessibility tree, so getByRole() and getByLabel() cannot see it — a rare case where a scoped CSS query is the correct tool rather than a compromise, unlike the general preference argued in Why getByRole Beats CSS Selectors in Modern Apps. Second, clicking the visible proxy hands control to the operating system, and the browser process cannot script that dialog in any mode, headed or headless. Playwright's answer is to skip the user-facing path entirely: setInputFiles() populates the element's FileList and dispatches input and change, which is exactly what the real picker would have produced.

Minimal reproducible example

The test below targets a component whose input carries display: none and sits inside a <form class="uploader">. Every line that is not obvious carries a comment explaining why it exists.

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

test('uploads through a hidden file input', async ({ page }) => {
  await page.goto('/documents');

  // The visible control is a styled <label>; the real input is display:none.
  // Role and label queries skip hidden nodes, so scope a CSS query instead.
  const input = page.locator('form.uploader input[type="file"]');

  // Only attachment matters here — setInputFiles never runs a visibility check,
  // but it will time out if the component has not rendered the input yet.
  await expect(input).toBeAttached();

  // Absolute path: the working directory of a CI runner is not your repo root.
  await input.setInputFiles(path.join(__dirname, 'fixtures', 'invoice.pdf'));

  // setInputFiles dispatches input and change, so framework handlers do run.
  // Assert on what the app renders, not on the call returning.
  await expect(page.getByText('invoice.pdf')).toBeVisible();
});

Nothing in that test clicks the label. Clicking it would be legitimate only if you intended to intercept the resulting picker, which is the second shape of the problem and needs a different API. Two details in that snippet repay attention. The accept attribute on a hidden input is advisory only — it filters what the real picker offers a human, and setInputFiles() ignores it, so a test can assign a .exe to an input that advertises accept=".pdf" and will then be testing the server's validation rather than the browser's. And the assertion targets rendered text rather than the input's own value property, which browsers deliberately report as a fake path such as C:\fakepath\invoice.pdf for privacy reasons; asserting on that string is a habit worth breaking early.

Step-by-step fix

1. Locate the real input, never the visible proxy. Open the component in the inspector and find the <input type="file">. Scope the query to the surrounding form or component root — page.locator('[data-testid="uploader"] input[type="file"]') — so it stays unique when a second uploader appears on the page. If the widget wraps the input in a <label> with a for attribute, pointing the locator at that label also works, because Playwright resolves a label to its associated control.
2. Assert attachment instead of visibility. Use await expect(input).toBeAttached() or input.waitFor({ state: 'attached' }). The default toBeVisible() assertion will fail forever against a hidden input, and waitFor() without an explicit state defaults to visible, which is the single most common self-inflicted timeout on this pattern.
3. Pass absolute paths or in-memory buffers. setInputFiles() resolves relative paths against the process working directory, which differs between a local run and a container. Use path.join(__dirname, ...) for fixture files, or skip the filesystem entirely with { name, mimeType, buffer } when the content is generated by the test.
4. When the input is created on click, race the filechooser event. Some widgets build the input inside the click handler, so there is nothing to target beforehand. Create the page.waitForEvent('filechooser') promise before the click, await both together, then call fileChooser.setFiles().
5. When there is no input at all, dispatch a synthetic drop. Pure drag-and-drop zones listen for drop and read event.dataTransfer.files. Build a DataTransfer inside the page with page.evaluateHandle(), add a real File to it, and hand it to locator.dispatchEvent('drop', { dataTransfer }).
6. Wait for the application's own confirmation. setInputFiles() resolves as soon as the assignment is made; the upload request happens afterwards. Gate the next step on a rendered filename, a progress bar reaching completion, or page.waitForResponse() against the upload endpoint, in the spirit of the Web-First Assertions approach.
7. Reset the control between scenarios. Calling await input.setInputFiles([]) clears the FileList and fires change with an empty selection, which is the correct way to test validation messages and to prevent leftover state when one spec reuses a page across steps.

The click-created variant looks like this. Note that the promise is created first and awaited second — the same ordering every event-driven Playwright API expects.

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

test('uploads when the input only exists after a click', async ({ page }) => {
  await page.goto('/media');

  // Subscribe first: the event is emitted synchronously with the click.
  const chooserPromise = page.waitForEvent('filechooser');
  await page.getByRole('button', { name: 'Add media' }).click();
  const chooser = await chooserPromise;

  // isMultiple() mirrors the multiple attribute on the underlying input.
  expect(chooser.isMultiple()).toBe(true);

  // setFiles takes the same argument shapes as setInputFiles.
  await chooser.setFiles([
    path.join(__dirname, 'fixtures', 'shot-a.png'),
    path.join(__dirname, 'fixtures', 'shot-b.png'),
  ]);

  await expect(page.getByRole('listitem')).toHaveCount(2);
});

For a zone that never creates an input, construct the payload in page context. dispatchEvent() is one of the few methods that skips actionability entirely, so the zone does not have to be scrolled into view.

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

test('drops a file on a zone that has no file input', async ({ page }) => {
  await page.goto('/upload');
  const bytes = Array.from(readFileSync(path.join(__dirname, 'fixtures', 'report.csv')));

  // Build the DataTransfer inside the page: File and DataTransfer are browser
  // classes, so they cannot be constructed in the Node test process.
  const dataTransfer = await page.evaluateHandle((data) => {
    const dt = new DataTransfer();
    dt.items.add(new File([new Uint8Array(data)], 'report.csv', { type: 'text/csv' }));
    return dt;
  }, bytes);

  const zone = page.getByTestId('dropzone');
  // Many zones only mount their drop handler after dragenter/dragover.
  await zone.dispatchEvent('dragenter', { dataTransfer });
  await zone.dispatchEvent('dragover', { dataTransfer });
  await zone.dispatchEvent('drop', { dataTransfer });

  await expect(page.getByText('report.csv')).toBeVisible();
  await dataTransfer.dispose();
});

Disposing the handle matters in long specs: an undisposed JSHandle keeps the DataTransfer and its File alive in the page for the lifetime of the context, and a scraper-style loop that drops a hundred files will grow the renderer's heap until the worker is killed. The synthetic drop is also the only technique on this page that fakes a browser behaviour rather than driving one, so treat it as the last resort the decision tree makes it: if the component keeps a hidden input as a fallback for keyboard users — and accessible ones do — target that input instead and you get real event flow for free.

Uploads that must not reach a real backend are the natural place to combine this with route interception. Fulfilling the multipart request with a canned success or a 413 response, as covered in Mocking API Responses with Playwright, lets one fixture file drive the success path, the quota-exceeded banner, and the retry prompt without provisioning storage or waiting on a slow upload.

Troubleshooting variants

The call throws "Node is not an HTMLInputElement"

Your locator resolved to the wrapper — a <div>, a <button>, or a styled span — rather than the input. Playwright accepts an <input type="file"> or a <label> that has an associated control, and rejects anything else. Re-anchor the selector on the input itself, and if the widget renders the input outside the visible component (some libraries append it to document.body), scope by attribute instead of by ancestry: page.locator('input[type="file"][accept=".pdf"]'). When several uploaders coexist you will trade this error for a strict mode violation, which the techniques in Resolving Strict Mode Violations resolve — filter by an enclosing labelled section rather than reaching for .first().

The chooser event never arrives

Three causes account for nearly all of these. The subscription came after the click, which the diagram above illustrates. The button does not actually open a picker — it calls window.showOpenFilePicker() from the File System Access API, which Playwright does not intercept and which needs a different strategy, usually stubbing the API with an init script. Or the click was swallowed by an overlay, in which case the trace shows the click landing on a different element. A related failure is Non-multiple file input can only accept single file, thrown when you pass an array of two or more paths to an input without the multiple attribute; the fix is one call per input, or the batching patterns in Handling Multiple File Uploads in Playwright.

The files land but the application never reacts

Check the FileList first with await input.evaluate((el: HTMLInputElement) => el.files?.length). If it reports the right count, the assignment worked and the problem is downstream. Components that re-render on every keystroke sometimes replace the input node between your toBeAttached() check and the call, producing Element is not attached to the DOM; Playwright retries the resolution, but a component that remounts in a loop needs a stable anchor, and the synchronization patterns in Waiting Strategies for Dynamic React Components apply directly. Some widgets also bind to drop or to a custom event rather than to change, in which case no assignment on the input will ever notify them and the synthetic drop is the only route.

Verification

Prove the upload three ways, from cheapest to most conclusive. Assert on the DOM the application produced — a filename chip, a thumbnail, or a disabled submit button turning active — because that state only exists if the change handler ran. Then assert on the wire: wrap the action in page.waitForResponse(response => response.url().includes('/api/upload') && response.status() === 201) so a silently swallowed request cannot pass as success. Finally, when a failure is not obvious, open the recording in the Playwright Trace Viewer: the setInputFiles step records the resolved element and the DOM snapshot around it, so you can confirm the locator hit the input rather than its wrapper, and the network tab shows whether the multipart request left the browser. Run the spec once in a container as well — the paths that work from your editor's working directory are the first thing to break under Dockerized headless CI. For anything where corruption would be expensive, close the loop: upload a fixture, then pull the stored copy back through the download flow described in Automating File Downloads and Verifying Contents and compare the bytes. A round-trip test catches encoding damage and truncation that no DOM assertion can see, and it runs in a second against a small fixture.

Frequently Asked Questions