Implicit vs explicit vs fluent wait in Selenium
Updated 2026-11-13 · 2 min read
Compare Selenium waits, understand Java FluentWait and WebDriverWait, and avoid mixing timing policies. Includes a comparison table, concrete examples and an interview answer.
The difference in one table
| Aspect | Implicit wait | Explicit wait | FluentWait in Java |
|---|---|---|---|
| Scope | Session-level element lookup timeout | A chosen condition at a chosen point | Configurable implementation for condition-based waiting |
| Waits for | Matching elements to be found | A condition such as visibility or a state change | The condition supplied to its until method |
| Configuration | Element lookup timeout | Timeout and condition; other controls depend on binding | Timeout, polling interval and ignored exception types |
| Relationship | Separate element-search policy | A waiting technique | WebDriverWait extends this class |
| Common mistake | Expecting it to wait for an element to become usable | Waiting for presence when visibility is needed | Treating it as a third unrelated waiting mechanism |
Examples
Implicit: if a search input is inserted after navigation, an element lookup can wait for a match within the implicit timeout. It does not establish that the input is visible and enabled.
Explicit: after choosing a payment option, wait for the confirmation control to reach the state required by the next action. Choose the condition deliberately: presence and visibility answer different questions.
FluentWait: in Java, a custom wait might poll an application-specific state and ignore only a known transient exception. It is still an explicit wait. WebDriverWait is the WebDriver-focused subclass; its inherited configuration also allows polling adjustments.
How to answer in an interview
Implicit wait sets a session-wide timeout for element searches, while an explicit wait targets a condition at a particular point. In Java, FluentWait is a configurable class used for explicit waiting, and WebDriverWait extends it. I choose the condition needed by the next step rather than adding a fixed sleep. I avoid mixing implicit and explicit waits because their timing can interact unpredictably.
Common confusion
“Fluent wait” is often interview shorthand for custom polling and exception handling, not a separate Selenium timing model. Binding APIs differ, so this class relationship specifically describes Java. Do not ignore every exception: invalid selectors and other real defects should fail clearly.
Likely follow-up: Does a wait always pause for the full timeout? No: it returns when its success condition is met; the timeout bounds waiting rather than prescribing a sleep.
Quick answers
Does a clickable condition guarantee a click succeeds?
No. The page can change between the condition and the action; overlays or rerendering can still require investigation.
Should I solve flakiness with longer waits everywhere?
No. Check the required state, locator, frame and application behaviour first. Longer timeouts can hide slow failures without fixing the cause.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.