Uploading Files Without a Native OS Dialog
A file input rendered as <input type="file"> normally opens the operating system's native file picker when clicked, and WebDriver has no ability to control OS-level dialogs since they exist entirely outside the browser process. The trick is that you never need to open the dialog at all: calling sendKeys() with the absolute file path directly on the <input type="file"> WebElement sets its value exactly as if a user had picked that file, without any dialog ever appearing, because the browser accepts a programmatically-set path from WebDriver the same way it accepts one selected through the OS picker. This only works on the raw <input> element itself, so if it's visually hidden and a styled button is stacked on top of it (common with custom-styled upload widgets), you must locate the actual hidden input, not the decorative button, and it must not have display:none applied, though visibility:hidden or a zero-size input is usually acceptable to most browsers.
Cricket analogy: A DRS umpire's call doesn't require the third umpire to physically walk onto the field, the decision propagates through the system directly; sendKeys() on a file input propagates the file path directly without any OS dialog appearing.
WebElement fileInput = driver.findElement(By.cssSelector("input[type='file']"));
// No OS dialog ever opens; the absolute path is set directly on the input
fileInput.sendKeys("/home/user/test-data/resume.pdf");
driver.findElement(By.id("upload-submit")).click();
// Verify the upload succeeded by checking the resulting UI state
WebElement confirmation = new WebDriverWait(driver, Duration.ofSeconds(10))
.until(ExpectedConditions.visibilityOfElementLocated(By.className("upload-success")));
assert confirmation.getText().contains("resume.pdf");
If the <input type="file"> element has CSS display:none applied (rather than being merely visually clipped or zero-sized), most browsers treat it as truly hidden and sendKeys() will throw ElementNotInteractableException. Use JavascriptExecutor to temporarily adjust the style attribute, or check whether the site exposes an alternate visible input, before falling back to display:none removal as a last resort.
Uploading in Remote/Grid Environments
When tests run against a remote WebDriver (Selenium Grid, a cloud provider like BrowserStack or Sauce Labs, or a Dockerized browser node), the file must exist on the filesystem of the machine running the browser, not on the machine running your test code — a local absolute path that works fine locally will fail on a remote node because that path doesn't exist there. RemoteWebDriver historically solved this via LocalFileDetector, which intercepts sendKeys() calls to file inputs, transparently zips and uploads the local file to the remote node's temp directory, and rewrites the path before it reaches the browser, so the same sendKeys(localPath) code works unmodified whether running locally or against a grid.
Cricket analogy: A player's kit bag needs to physically travel with them to the away ground; it doesn't magically appear at the opposition's stadium just because it exists at home. LocalFileDetector is the courier that physically moves the file to the correct remote machine first.
// Selenium 4: enable LocalFileDetector so sendKeys() transparently uploads
// the local file to the remote grid node before the browser sees the path
RemoteWebDriver driver = new RemoteWebDriver(new URL("http://grid-hub:4444/wd/hub"), options);
driver.setFileDetector(new LocalFileDetector());
driver.get("https://example.com/upload");
WebElement fileInput = driver.findElement(By.cssSelector("input[type='file']"));
fileInput.sendKeys("/home/user/test-data/resume.pdf"); // path on the local test-runner machine
Verifying Downloads
Selenium has no built-in API for inspecting a completed file download because downloads happen through the browser's native download manager, entirely outside WebDriver's control surface; verification instead relies on configuring the browser to download automatically without a save-as prompt (via ChromeOptions preferences like download.default_directory and download.prompt_for_download disabled) and then polling that known local directory from the test code itself, checking for the expected filename to appear and its size to stabilize (stop growing between polls) before asserting on its contents. For headless CI environments, remember the download directory preference must point to a path the test runner process itself can also read, since verification happens by reading the filesystem directly, not through any WebDriver command.
Cricket analogy: A stadium's Hawk-Eye system tracks the ball's landing point after it leaves the bowler's hand, external to the umpire's own view, and results are read from that separate tracking system; verifying a download reads from the separate filesystem, external to WebDriver's own view.
In ChromeOptions, set prefs.put("download.default_directory", downloadDir) and prefs.put("download.prompt_for_download", false) so downloads save silently to a known, predictable folder your test code can poll — without this, Chrome shows a native save dialog that WebDriver cannot interact with, identical in principle to the file-picker problem on uploads.
- sendKeys(absolutePath) on an <input type="file"> sets the file directly, bypassing the OS file picker dialog entirely.
- The hidden actual <input type="file"> must be located (not a decorative styled button on top of it), and it must not have display:none for sendKeys() to work.
- On RemoteWebDriver/Selenium Grid, the file path must exist on the browser node's machine; LocalFileDetector transparently uploads the local file to the remote node first.
- Selenium has no native API to inspect downloads since they occur through the OS/browser download manager, outside WebDriver's control.
- Configure ChromeOptions to auto-download without a save-as prompt (download.default_directory, download.prompt_for_download=false).
- Verify downloads by polling the known local directory for the expected filename and a stabilized file size.
- In CI, the configured download directory must be readable by the test runner process, since verification reads the filesystem directly.
Practice what you learned
1. How does Selenium upload a file to a web form without ever opening the operating system's native file picker dialog?
2. Why does sendKeys() sometimes throw ElementNotInteractableException on a custom-styled upload widget?
3. Why does a local absolute file path passed to sendKeys() fail when running against a Selenium Grid node on a different machine?
4. What does setFileDetector(new LocalFileDetector()) accomplish on a RemoteWebDriver instance?
5. Why can't Selenium directly verify that a file download completed successfully through a WebDriver API call?
Was this page helpful?
You May Also Like
JavaScriptExecutor for Tricky Elements
Learn how JavascriptExecutor lets Selenium run arbitrary JavaScript to work around interactability limitations, and when relying on it can mask real bugs.
Working with Frames and Multiple Windows
Learn how to switch WebDriver's context into iframes and nested frames, and how to detect, switch between, and close multiple browser windows and tabs.
Handling Alerts and Popups
Understand how to detect, read, and respond to native JavaScript alert, confirm, and prompt dialogs, and how to tell them apart from ordinary DOM-based popups.