Implicit wait

An implicit wait tells WebDriver to keep looking for an element for a fixed time before giving up. You set it once per driver session and it applies to every findElement and findElements call from then on. It is “implicit” because the waiting happens silently inside element lookup rather than at a point you choose. The default is zero.

Example (Selenium 4, Java)

driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(5));

// Polls for up to 5 seconds for the element to exist in the DOM
WebElement email = driver.findElement(By.id("email"));

// findElements also waits up to 5 seconds, then returns an empty list
List<WebElement> errors = driver.findElements(By.cssSelector(".error"));

In Selenium 4 the Duration overload is the one to use. The older implicitlyWait(long, TimeUnit) is deprecated.

How it differs from an explicit wait

	Implicit wait	Explicit wait
Scope	Every element lookup for the session	One condition at one point in the test
What it waits for	The element to exist in the DOM	Any condition: visible, clickable, text present, gone
Where it is set	Once, on the driver	Inline, with WebDriverWait

An implicit wait does not wait for an element to be visible or enabled. If the button exists but is still disabled, findElement returns immediately and the click may fail or do nothing.

Why many teams avoid it

• Mixing it with explicit waits is unpredictable. Selenium’s documentation warns against combining them, because the lookups inside an explicit wait also apply the implicit timeout.
• Checking that something is absent becomes slow. findElements(...).isEmpty() waits the full implicit timeout every time the element is correctly missing.
• It hides the intent. A reader cannot tell which steps actually need to wait.

The common recommendation is to leave the implicit wait at zero and use explicit waits where they are needed. If a legacy suite relies on one, keep it short and don’t add explicit waits on top without removing it.