Recommended Free Tools
Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
If Selenium finds an <a> element but cannot click it, first identify the exact WebDriver error. A successful locator does not prove that the link is ready for a real pointer click: Selenium scrolls the target into view and clicks its center, which may be covered by an overlay or fall outside the anchor’s usable bounds. Use an explicit wait for the page condition you need, inspect the target point, and choose a fix that addresses the cause rather than defaulting to JavaScript.
What the click error tells you
WebDriver’s click is an interaction, not just a command to activate a DOM node. It checks whether the element is interactable, scrolls it into view when necessary, and targets the center of its visible rectangle. Selenium’s interaction documentation explains: “If the center of the element is obscured for some reason, Selenium will return an element click intercepted error.” Selenium: Interactions
| Error | What it usually indicates | First thing to inspect |
|---|---|---|
ElementClickInterceptedException |
Another element covers the requested click point. | Overlay, sticky header, modal, loading mask, or the anchor’s geometry. |
ElementNotInteractableException |
The target does not currently support the requested pointer or keyboard interaction. | Visibility, enabled state, whether the link is off-screen or covered, and whether the actual interactive target is a descendant. |
StaleElementReferenceException |
The stored reference no longer points to an attached DOM node, often after a rerender. | Whether the application replaced the element after you located it. |
NoSuchElementException |
The locator did not find a matching element at the time it ran. | Locator accuracy, frame or window context, and whether the element has been rendered. |
| Timeout from a wait | The condition did not become true before the wait expired. | Whether the condition matches the page’s real state and whether the locator identifies the intended link. |
These distinctions follow the WebDriver error reference; they are starting points for diagnosis, not a claim that every page has the same cause. MDN: WebDriver errors
Wait for the condition the link needs
A navigation reaching a browser readyState does not guarantee that JavaScript-driven UI changes have finished. A link can appear later, become enabled after data loads, or move while an animation runs. Selenium recommends synchronizing on a meaningful condition rather than relying on a fixed sleep. Its wait guidance also warns that mixing implicit and explicit waits can produce unpredictable total wait times. Selenium: Waits
#1 Best Overall
In Python, use an explicit wait for visibility and enabledness as a sensible first check:
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
link = WebDriverWait(driver, 10).until(
EC.element_to_be_clickable((By.CSS_SELECTOR, "a.some-link"))
)
link.click()Replace a.some-link with a selector for the actual link. element_to_be_clickable checks that the element is visible and enabled; it cannot guarantee that an unrelated element will not cover the center point a moment later. If this wait succeeds but the click is intercepted, investigate the click point instead of simply extending the timeout. Selenium Python expected conditions
Wait for the application state, not just the element
Choose a condition that represents what the test needs immediately before the click: for example, a loading indicator disappearing, a menu opening, or the link becoming visible and enabled. Keep the wait bounded and specific. A fixed sleep may be too short on a slow run and unnecessarily long on a fast one; it is not a substitute for a state check.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
Do not combine implicit waits with explicit waits as a general fix. Selenium documents that mixing them can make wait durations unpredictable. If the page is asynchronous, a targeted explicit wait is easier to reason about.
Inspect the point Selenium is trying to click
When an intercepted error names another element, inspect the page at the time of failure. Common blockers include a consent banner, sticky navigation, modal, tooltip, chat widget, or temporary loading mask. The key question is not simply whether the anchor is visible, but whether its center is unobstructed when WebDriver clicks.
- Capture the exact exception and any message identifying the intercepting element.
- Inspect the page at failure time, including overlays and elements positioned above the link.
- Check whether the link moved during scrolling, animation, or a rerender.
- Confirm that the anchor’s center is inside its intended clickable area.
ChromeDriver documents a less obvious geometry case: an anchor’s clickable descendant can extend outside the anchor’s bounds, so the calculated target may not land on the intended clickable content. Its troubleshooting guidance describes cause-specific options including clicking a child, removing a blocker, using a pointer offset, or simulating a JavaScript mouse click. ChromeDriver: Clicking issues
Choose a remedy that matches the cause
| Cause | Appropriate remedy | Trade-off |
|---|---|---|
| The link is not ready yet | Wait for the relevant application state, then locate or click the link. | Does not solve an overlay or incorrect hit target. |
| A legitimate overlay blocks the link | Use the UI to dismiss it, or arrange the test state so it is absent when appropriate. | Do not remove an obstruction if handling it is part of the behavior under test. |
| A clickable child is the real target | Locate and click that descendant if it is the actual interactive target. | Depends on the page’s DOM and can be brittle if markup changes. |
| The center is blocked but another point inside the link is safe | Use Selenium’s advanced pointer interactions to click a deliberate offset. | Offsets depend on geometry and may fail at different viewport sizes or responsive layouts. |
| The test intentionally needs script-level activation | Use a JavaScript mouse click only with a clear reason, or as a diagnostic comparison. | It does not reproduce ordinary pointer hit-testing and can conceal a real user-facing defect. |
Dismiss a blocker through the tested flow
If the test is supposed to handle a consent dialog or modal, interact with its button and wait for it to disappear before clicking the link. Removing or hiding an element through test setup is only appropriate when the blocker is not itself part of the behavior being verified. Otherwise, the test would skip an important user interaction.
Try a descendant or a pointer offset only when geometry warrants it
For an anchor with a child that receives the actual interaction, target that child if it is a valid user-facing target. If a safe point exists within the anchor, Selenium’s advanced interactions API can move to an offset from its top-left and click. Verify that the chosen point remains valid at the viewport sizes the test supports; a coordinate that works in one layout is not automatically robust in another.
Keep JavaScript clicks exceptional
A script-triggered click can help determine whether the event handler works when normal pointer hit-testing is bypassed. That difference is also its limitation: if a real user cannot reach the link because something covers it, JavaScript activation can make the test pass while leaving the defect intact. Prefer it only when script-level activation is what the test intends to exercise, not as an automatic replacement for WebDriver interaction.
Handle movement, rerenders, and stale references
A target that changes location between location calculation and the click can lead to a not-clickable failure. ChromeDriver advises waiting for a moving element to stop; its documentation says, “If the element eventually stops, wait for that to occur.” This does not promise a remedy when the element never settles. Wait for the relevant animation or application state when possible, then perform the interaction.
If the page rerenders and replaces the anchor node, an earlier WebElement becomes stale. Wait for the updated condition and find the element again rather than repeatedly using the old reference. Retrying can be reasonable for a transient movement or rerender, but an unbounded retry loop can hide a persistent layout or application problem.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Verify the result after clicking
A click command completing does not prove that the expected destination or application state is ready. For a link that navigates, wait for the expected URL, title, destination element, or new window as appropriate. For an in-page handler, wait for the state change the application is supposed to produce. This separates a successful interaction from a later navigation or rendering delay. Selenium’s wait guidance supports synchronizing against the specific condition the test needs. Selenium: Waits
Troubleshooting by symptom
- Wait succeeds, click is intercepted: Visibility and enabledness passed, but the center can still be covered. Inspect the named covering element and the anchor’s bounds.
- Click fails only during page load: Wait for the application condition that reveals or stabilizes the link, not merely document readiness.
- Click fails after scrolling: Check sticky elements and whether the center point is overlapped after scrolling.
- Click works at one viewport but not another: Responsive layout may change the link’s geometry or place an overlay over it. Validate the target point at the relevant viewport sizes.
- Stale reference after a click or update: Reacquire the link after the DOM update and wait for the new node or state.
- Click command succeeds but the test times out next: Wait for the intended navigation or application state separately; do not assume the click command verifies it.
Or skip the browser setup
If your task is to capture a page rather than test a real Selenium interaction, ScreenshotNeo provides a website screenshot API and MCP server. One GET request can return a screenshot or PDF; the API also offers options such as full-page capture, CSS selectors, custom waits, and browser settings. For Selenium-specific behavior, retain the browser test and the hit-target diagnosis above.
cURL example:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpPython example:
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)Node.js example:
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);See the ScreenshotNeo API documentation for request details. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents use screenshot tools, and the Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for ScreenshotNeo free.
Frequently Asked Questions
Does `element_to_be_clickable` guarantee Selenium can click an anchor?
No. It checks visibility and enabledness, but another element can still cover the center point at click time.
Should I use JavaScript to click every link Selenium cannot click?
No. A JavaScript click can bypass normal pointer hit-testing, so reserve it for an intentional script-level interaction or diagnosis.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
