Implicit Wait vs. Explicit Wait in Selenium

An implicit wait sets a session-wide timeout for element-location calls. An explicit wait polls for a specific condition at the point your test needs it. For dynamic pages, prefer explicit waits and keep the implicit wait at zero. Selenium warns that combining the two can make total wait times unpredictable.

How the two waits differ

Question	Implicit wait	Explicit wait
Scope	Session-wide, for element-location calls	Local to a wait invocation
What it waits for	The requested element to be found	A chosen condition, such as visibility or clickability
How it works	Retries element lookup until success or timeout	Polls a condition until it succeeds or times out
Typical use	A deliberate global lookup policy	Dynamic UI state and readiness for the next action
Main risk	Can add delay to many lookups and slow tests	A poor condition or timeout can still cause failures
Using both	Avoid it: Selenium documents unpredictable combined timing.

The default implicit wait is zero. With no wait configured, a missing element lookup can fail immediately. An implicit wait does not mean “wait until the element is visible”: it only affects whether a lookup finds the element. To wait for visibility, text, or another state change, use an explicit condition. See Selenium’s Waiting Strategies and Expected Conditions.

Use an explicit wait for the state your test needs

Choose the condition that makes the next operation safe. If the test is about clicking a button, wait until it is clickable. If it needs text, wait for that text. A page-load event alone may not be enough: navigation waits for the configured page-load strategy’s readyState (normally complete), but JavaScript may still be updating the interface.

Python: wait until a button is clickable

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.support.wait import WebDriverWait

# Install Selenium with: python -m pip install selenium
driver = webdriver.Chrome()
try:
    driver.get("https://example.com")
    wait = WebDriverWait(driver, timeout=10)
    button = wait.until(EC.element_to_be_clickable((By.ID, "submit")))
    button.click()
finally:
    driver.quit()

Replace the example URL and element locator with values from your page. The condition matters: finding an element does not establish that it is visible or ready to click. Python’s WebDriverWait polls every 0.5 seconds by default and ignores NoSuchElementException by default; those are Python binding details, not universal defaults for every Selenium language.

Java: set an implicit wait only when you mean to

import java.time.Duration;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

WebDriver driver = new ChromeDriver();
try {
    driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(2));
    driver.get("https://example.com");
    // Element lookups now use this session-wide timeout.
} finally {
    driver.quit();
}

This configures a global lookup timeout; it does not wait for visibility or clickability. If the test uses explicit waits, leave this at zero. Selenium’s Java API cautions that a longer implicit timeout can adversely affect runtime, particularly with slower location strategies such as XPath. Check the API for your language and Selenium version because method names and condition support differ by binding. Selenium’s documentation notes that .NET stopped supporting its Expected Conditions in Selenium 4.

Why Selenium says not to mix the waits

Selenium’s documentation gives this warning: “Do not mix implicit and explicit waits. Doing so can cause unpredictable wait times.” An explicit wait repeatedly evaluates its condition, and element lookups inside that condition can themselves be affected by the implicit timeout. As a result, the explicit timeout should not be treated as a hard upper bound while a nonzero implicit wait is active.

Selenium illustrates the issue with a 10-second implicit wait and a 15-second explicit wait: the wait can time out after 20 seconds. That is a documentation example, not a general benchmark or a guarantee that every driver will take the same time. The safe configuration for explicit-wait tests is an implicit timeout of zero.

Choose a wait and configure it deliberately

Set the implicit wait to zero when your synchronization strategy uses explicit waits. Zero is Selenium’s default; avoid setting a nonzero global timeout as a hidden fallback.
Identify the next required browser state. Decide whether the test needs an element to exist, become visible, become clickable, contain text, or satisfy another condition.
Wait for that condition. Use an explicit wait at the point where the state is needed. It proceeds as soon as the condition succeeds, instead of sleeping for a fixed duration regardless of page speed.
Choose a timeout that matches the operation. A timeout is a failure boundary, not a guarantee that a slow operation will become valid. Use the smallest reasonable bound for the page and environment.
Keep waits near the action they protect. Local waits show why the test is waiting and make failures easier to diagnose.
Check the binding’s API. Available conditions, polling controls, and ignored exceptions vary by language and Selenium version.

Polling and exception behavior

An explicit wait is a polling loop. Depending on the binding, you may be able to configure its timeout, polling frequency, ignored exceptions, and timeout message. In Python, WebDriverWait accepts those settings; its default polling interval is 0.5 seconds and its default ignored exception is NoSuchElementException. Do not assume those defaults apply to Java, JavaScript, .NET, or Ruby. Verify the relevant binding documentation before changing polling or exception handling.

Ignore only exceptions that are expected while the page transitions. Broadly suppressing errors can hide a broken locator, an invalid test assumption, or a real page failure. Prefer a condition that expresses the intended state over adding more ignored exceptions.

Common errors and fixes

Symptom	Likely cause	Fix
Element lookup fails immediately	The implicit wait is zero and the element is not present yet.	Use an explicit wait for the element’s required state.
Element is found but interaction fails	Presence was mistaken for visibility or readiness.	Wait for visibility or clickability, as appropriate, rather than relying on an implicit wait.
Explicit wait takes longer than its timeout	A nonzero implicit wait may be extending element lookups inside each poll.	Set the implicit wait to zero and use the explicit condition’s timeout. Selenium documents this interaction as unpredictable.
Test is flaky after navigation	The document reached its configured ready state, but a JavaScript-driven change is still underway.	Wait for the specific UI condition required by the next step.
Wait times out even though the page looks ready	The locator or condition may not match the actual state, or the state may be transient.	Inspect the locator and condition, confirm the expected text/state, and make the timeout failure message useful.
Tests become much slower after raising an implicit timeout	The global timeout can affect many failed or slow lookups; locator strategy also matters.	Return the implicit wait to zero for explicit-wait tests. Use a local condition wait where needed.
Expected Condition example does not compile or import	The API differs by binding or Selenium version; .NET’s Selenium 4 support differs from other bindings.	Use the current documentation for the language binding and version in the project.

Performance, reliability, and cost

Performance: A longer implicit timeout can make test suites slower because it applies to element-location calls across the session. XPath and other slower lookup paths can make the cost more noticeable. Explicit waits can proceed as soon as their conditions are true, so they avoid a fixed sleep that always consumes its full duration. Poorly chosen timeouts and conditions can still waste time or cause failures.

Reliability: Wait for the state the next line depends on. A page-load completion signal does not guarantee that client-side rendering or an asynchronous request has finished. Fixed sleeps are a weak primary synchronization strategy: they can be too short on a slow run and needlessly long on a fast one.

Cost: Selenium wait settings do not have a separate price in the cited documentation. Their practical cost is test execution time and the debugging effort caused by flaky synchronization. Avoid turning a generous global delay into a silent substitute for a condition-specific wait.

Or skip the browser setup

If your goal is a current screenshot of a page rather than browser interaction and assertions, ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Its browser capture waits can target a selector, a delay, or network idle, and it supports full-page capture, element capture, custom CSS and JavaScript, and other capture options. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed, and responses identify the page verdict and billing status in headers. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

FAQ

Can I use implicit and explicit waits together?

Selenium advises against it because the combined wait time can be unpredictable. Keep implicit wait at zero when using explicit waits.

Does an implicit wait wait for an element to become visible?

No. It affects whether element-location calls find the element. Use a visibility condition when visibility is what matters.

Which wait should I use for a dynamic element?

Use an explicit wait for the particular state needed before the next action. Leave the implicit wait at zero.

Why can an explicit wait exceed its configured timeout?

A nonzero implicit wait can affect lookups performed during condition polling. Selenium warns that the combined timing is unpredictable.