How to Handle alerts in Selenium (2026)

TL;DR

To handle JavaScript alerts in Selenium, wait for a JavaScript dialog, inspect its text, accept or dismiss it, enter prompt text when supported, and distinguish dialogs from ordinary HTML modals. Use Selenium 4 public APIs, explicit waits, precise assertions, isolated test state, and reliable cleanup.

Key Takeaways

• Treat JavaScript alerts in Selenium as a state transition with a clear postcondition.
• Use explicit, bounded synchronization instead of fixed sleeps.
• Verify the business result, not only that WebDriver issued a command.
• Keep test data and artifacts isolated for safe parallel execution.
• Capture diagnostic context without exposing secrets or personal data.
• Run the scenario with CI-equivalent browser and environment settings.

selenium how to handle alerts means more than making WebDriver perform an action. The dependable solution is to wait for a JavaScript dialog, inspect its text, accept or dismiss it, enter prompt text when supported, and distinguish dialogs from ordinary HTML modals. This guide shows a Java and Selenium 4 approach that remains readable in local runs, headless CI, and remote execution.

The examples use public WebDriver APIs and JUnit 5. Selenium Manager is available through the normal driver constructor, so the examples do not hard-code a driver executable path. Adapt locators and application URLs to your system, but keep the synchronization, evidence, security, and assertion boundaries intact.

TL;DR

• Identify the browser or application state that proves the operation is ready.
• Use a bounded explicit wait, not a fixed sleep.
• Verify the business result, not only the WebDriver command.
• Isolate test data and execution artifacts for parallel safety.
• Capture safe diagnostic context and always clean up.

1. Know Which Popup Selenium Is Handling

Distinguish browser JavaScript dialogs from DOM modals, permission prompts, and new windows. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Calling switchTo alert on an HTML dialog always fails. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Inspect whether the popup appears in the DOM and whether browser chrome owns it. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. The related guide to Selenium explicit waits in Java provides a useful pattern when this flow has synchronization or design concerns.

What to assert

The selected API matches the popup type. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

2. Wait for an Alert Before Switching

Synchronize on alert presence after the triggering action. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Immediate switching races with asynchronous application code. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Use WebDriverWait and ExpectedConditions.alertIsPresent. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. The related guide to debugging failing Selenium tests provides a useful pattern when this flow has synchronization or design concerns.

What to assert

The timeout reports that the dialog did not appear. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

3. Accept a JavaScript Alert

Read expected text before accepting the blocking dialog. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Accepting immediately discards valuable evidence. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Switch once, store the Alert, assert getText, then accept. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. The related guide to maintainable page objects provides a useful pattern when this flow has synchronization or design concerns.

What to assert

The application reaches the expected post-accept state. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

4. Dismiss a Confirm Dialog

Exercise the cancel path and verify its business effect. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Testing only OK leaves destructive cancel behavior uncovered. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Trigger, wait, assert message, dismiss, and check that data remained unchanged. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. Keep the implementation close to the observable requirement so a reviewer can see why each wait and assertion exists.

What to assert

The cancel path protects the resource. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

5. Enter Text in a Prompt

Send deterministic input before accepting and verify how the page uses it. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Some browsers or applications normalize prompt text. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Call sendKeys on Alert, accept, then assert the resulting DOM or request outcome. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. Keep the implementation close to the observable requirement so a reviewer can see why each wait and assertion exists.

What to assert

The exact supported value is reflected safely. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

6. Handle Unexpected Alerts and Exceptions

Preserve context when a dialog blocks the next WebDriver command. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Blanket acceptance can hide a real product defect. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Capture the triggering step, dialog text, and screenshot after resolution where possible. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. Keep the implementation close to the observable requirement so a reviewer can see why each wait and assertion exists.

What to assert

UnexpectedAlertOpenException points to a named workflow transition. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

7. Test Alert Text Without Brittle Assertions

Assert stable meaning while preserving important security or legal copy. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Exact full-string assertions break on harmless punctuation changes. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Use exact text for contractual messages and focused contains checks for dynamic details. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. Keep the implementation close to the observable requirement so a reviewer can see why each wait and assertion exists.

What to assert

The assertion matches the requirement's level of precision. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

8. Configure Unhandled Prompt Behavior Carefully

Use browser capability behavior only as a safety policy. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Automatic dismissal can erase evidence and change the application path. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Prefer explicit handling in tests that expect a dialog and fail clearly on unexpected dialogs. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. Keep the implementation close to the observable requirement so a reviewer can see why each wait and assertion exists.

What to assert

Test intent remains visible in code. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

9. Separate Alerts, HTML Modals, and Windows

Route each popup to its correct Selenium mechanism. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Teams often call every overlay an alert. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Use Alert for JavaScript dialogs, locators for DOM modals, and window handles for tabs. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. Keep the implementation close to the observable requirement so a reviewer can see why each wait and assertion exists.

What to assert

No popup helper contains unrelated branching logic. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

10. Selenium How to Handle Alerts Checklist

Standardize trigger, wait, text assertion, action, and postcondition. That is the practical center of JavaScript alerts in Selenium. Start by naming the observable state before the action and the state expected afterward. A reliable test does not assume that a click, navigation, or command succeeded. It gathers evidence at the boundary where control moves between the test, browser, application, and operating environment.

Dialog tests become flaky when they skip synchronization or outcome checks. This matters most on CI, where CPU load, filesystem speed, browser policy, viewport, locale, and network routing may differ from a developer laptop. Keep the scenario narrow and make preconditions visible in setup. If the action depends on data, use a known record and log its nonsecret identifier. If it depends on browser state, assert that state before proceeding. These habits make a failed assertion explain the product behavior rather than merely report a timeout.

Implementation approach

Create small readable flows and reset state after each path. Prefer a bounded explicit wait over an unbounded retry. Re-locate elements after navigation or a component rerender, and reserve JavaScript execution for cases where it represents the supported behavior rather than a way to bypass the UI. Keep the implementation close to the observable requirement so a reviewer can see why each wait and assertion exists.

What to assert

Accept, dismiss, and prompt cases fail independently. Add a negative or boundary check when it protects a distinct risk. Assertion messages should include expected state, safe actual state, and the step being performed. Do not print tokens, passwords, personal data, or full payloads. On failure, preserve enough context to reproduce the issue, then let cleanup run even if evidence collection itself encounters an error. This produces a test that is diagnostic, reviewable, and safe to run repeatedly.

11. selenium how to handle alerts: Runnable Selenium 4 Java Example

The following example uses current, public Java APIs. Add Selenium Java and JUnit Jupiter to a Maven or Gradle test project, then run it with a locally installed supported browser. The normal driver constructor delegates driver discovery to Selenium Manager. Avoid copying only the central command. Setup, explicit synchronization, assertions, and cleanup are all part of the example's reliability contract.

import java.time.Duration;
import org.junit.jupiter.api.*;
import org.openqa.selenium.*;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.*;

class AlertTest {
  WebDriver driver;
  WebDriverWait wait;

  @BeforeEach void start() {
    driver = new ChromeDriver();
    wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    driver.get("https://www.selenium.dev/selenium/web/alerts.html");
  }

  @Test void acceptsAlert() {
    driver.findElement(By.id("alert")).click();
    Alert alert = wait.until(ExpectedConditions.alertIsPresent());
    Assertions.assertFalse(alert.getText().isBlank());
    alert.accept();
  }

  @Test void dismissesConfirm() {
    driver.findElement(By.id("confirm")).click();
    Alert confirm = wait.until(ExpectedConditions.alertIsPresent());
    confirm.dismiss();
  }

  @Test void completesPrompt() {
    driver.findElement(By.id("prompt")).click();
    Alert prompt = wait.until(ExpectedConditions.alertIsPresent());
    prompt.sendKeys("QAJobFit");
    prompt.accept();
  }

  @AfterEach void stop() { if (driver != null) driver.quit(); }
}

Keep this example small enough to debug. In a production framework, move repeated browser lifecycle and evidence capture into focused fixtures, while keeping the test's business intent visible. Never create a universal helper that catches every exception and returns a boolean, because that destroys the original stack trace and weakens failure diagnosis.

Run the scenario twice locally, then once with the same headless and browser arguments used by CI. A passing run should leave no shared state. A failing run should name the unmet condition and preserve safe evidence. Review debugging failing Selenium tests before turning the example into a larger page-object abstraction.

Interview Questions and Answers

A strong interview response explains both the Selenium API and the engineering reason behind it. Use the answers below as models, then add a brief example from your own framework.

Q: How do you wait for an alert in Selenium?

Use WebDriverWait with ExpectedConditions.alertIsPresent(). It returns the Alert when available and produces a bounded timeout when the dialog never appears.

Q: What is the difference between accept and dismiss?

accept chooses the affirmative action, usually OK. dismiss chooses the negative action, usually Cancel, and should have its own postcondition assertion.

Q: Can Selenium type into an alert?

Selenium can call sendKeys on a JavaScript prompt. A simple alert or confirm has no text field, so input is not applicable.

Q: Why does NoAlertPresentException occur?

The code switched too early, the wrong action was triggered, the popup is an HTML modal, or the dialog already closed. Synchronize on alert presence and confirm the popup type.

Q: Can you take a screenshot while an alert is open?

Behavior can vary because the dialog blocks page interaction and is browser-owned. Capture the alert text first, resolve it intentionally, then capture the resulting page state and logs.

Q: Should you set an unhandled prompt capability?

It can define a safety policy for unexpected dialogs, but it should not replace explicit handling in tests where the dialog is part of the requirement. Automatic behavior can hide the original cause.

Q: How do alerts differ from new windows?

An alert is a blocking JavaScript dialog accessed through Alert. A new window has its own handle and browsing context, so you wait for and switch to that handle.

Common Mistakes

• Calling switchTo().alert() before the dialog exists. Explain what state the test assumes, replace the assumption with an observable condition, and add a focused postcondition. During review, ask whether this mistake could create a false pass, a flaky failure, leaked data, or a result that cannot be diagnosed on CI.
• Treating a DOM modal as a JavaScript alert. Explain what state the test assumes, replace the assumption with an observable condition, and add a focused postcondition. During review, ask whether this mistake could create a false pass, a flaky failure, leaked data, or a result that cannot be diagnosed on CI.
• Accepting without first asserting important text. Explain what state the test assumes, replace the assumption with an observable condition, and add a focused postcondition. During review, ask whether this mistake could create a false pass, a flaky failure, leaked data, or a result that cannot be diagnosed on CI.
• Testing OK but never testing Cancel. Explain what state the test assumes, replace the assumption with an observable condition, and add a focused postcondition. During review, ask whether this mistake could create a false pass, a flaky failure, leaked data, or a result that cannot be diagnosed on CI.
• Automatically accepting every unexpected alert. Explain what state the test assumes, replace the assumption with an observable condition, and add a focused postcondition. During review, ask whether this mistake could create a false pass, a flaky failure, leaked data, or a result that cannot be diagnosed on CI.
• Failing to verify the application state after the dialog closes. Explain what state the test assumes, replace the assumption with an observable condition, and add a focused postcondition. During review, ask whether this mistake could create a false pass, a flaky failure, leaked data, or a result that cannot be diagnosed on CI.

Conclusion

The practical answer to selenium how to handle alerts is to wait for a JavaScript dialog, inspect its text, accept or dismiss it, enter prompt text when supported, and distinguish dialogs from ordinary HTML modals. The WebDriver call is only one part of the solution. Deterministic setup, state-based synchronization, business-focused assertions, secure evidence, and unconditional cleanup are what make the test trustworthy.

Start with one representative happy path, add the most valuable negative or boundary case, and run both under CI-equivalent conditions. Then extract only the mechanics that genuinely repeat. That sequence gives the team maintainable coverage without hiding the behavior that an engineer needs to understand when a test fails.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• How to Use Selenium DevTools in Selenium 4 in Java (2026)
• How to Debug a failing test in VS Code in Selenium (2026)
• How to Handle a date picker in Selenium (2026)
• How to Handle alerts in Cypress (2026)
• How to Handle alerts in Playwright (2026)
• How to Handle basic auth in Selenium (2026)