StaleElementReferenceException in Selenium: 7 Proven Fixes

Understanding the Error StaleElementReferenceException 

Quick answer: a StaleElementReferenceException means the WebElement you stored points to a DOM node that no longer exists — the page refreshed or JavaScript re-rendered it. Find the element again right before you use it, store By locators instead of WebElements, and re-fetch lists inside loops.

The Error

org.openqa.selenium.StaleElementReferenceException:
  stale element reference: element is not attached to the page document

Newer ChromeDriver versions word it as "stale element reference: stale element not found in the current frame". Same exception, same fixes.

What It Really Means

A WebElement is a reference to a DOM node — not the node itself. When findElement() runs, Selenium stores a pointer to that exact node in the browser. If the page refreshes, or JavaScript removes that node and inserts a new one — even an identical-looking one — your pointer now refers to a node that no longer exists.

That's why the element can be clearly visible on screen while Selenium says it's stale: you're holding a reference to the old copy. Think of it like a phone number for someone who changed their number — the person is still there, but the number you saved no longer reaches them.

Common Causes

• Page refresh or navigation — every DOM node is recreated.
• AJAX updates — a filter, sort or search rebuilds part of the page.
• JavaScript frameworks (React, Angular, Vue) re-render components when state changes.
• Switching frames, tabs or windows — references from another context become invalid.
• Storing elements too early — in Page Object fields, lists or variables reused after the page changed.

A Real-World Example

On an e-commerce page, selecting a price filter rebuilds the product list:

// ❌ Stale element
WebElement product = driver.findElement(By.className("product-name"));

driver.findElement(By.id("filter-price")).click();   // product list is rebuilt

product.click();                                      // 💥 StaleElementReferenceException

The product still appears on the page, but product points to the node from before the filter.

The 7 Fixes

Fix 1 — Re-locate the element right before using it ⭐

driver.findElement(By.id("filter-price")).click();

driver.findElement(By.className("product-name")).click();   // fresh reference

The simplest and most effective fix: find it at the moment you need it.

Fix 2 — Store By locators, not WebElements ⭐

// ❌ Caches a reference when the page object is created
public class ProductPage {
    private WebElement product =
        driver.findElement(By.className("product-name"));
}

// ✅ Stores the locator; finds a fresh element every time
public class ProductPage {
    private final By product = By.className("product-name");

    public void clickProduct() {
        driver.findElement(product).click();
    }
}

This one habit removes most stale-element failures across a framework. See Selenium Frameworks & Page Object Model.

Fix 3 — Wait for the old element to go, then find the new one

When an action replaces content, wait until the old element is detached before looking for the new one — otherwise you may grab the old node a split second before it disappears:

WebElement oldList = driver.findElement(By.id("results"));

driver.findElement(By.id("filter-price")).click();

WebDriverWait wait =
        new WebDriverWait(driver, Duration.ofSeconds(10));

wait.until(ExpectedConditions.stalenessOf(oldList));   // old list is gone

WebElement newList = wait.until(
        ExpectedConditions.visibilityOfElementLocated(By.id("results")));

Fix 4 — Use ExpectedConditions.refreshed()

refreshed() wraps another condition and treats a stale element as "not ready yet" instead of failing:

wait.until(ExpectedConditions.refreshed(
        ExpectedConditions.elementToBeClickable(
            By.className("product-name")
        )
)).click();

Fix 5 — Tell your wait to ignore stale references

For elements that re-render repeatedly while loading, a FluentWait can keep polling through stale moments:

Wait<WebDriver> fluent = new FluentWait<>(driver)
        .withTimeout(Duration.ofSeconds(10))
        .pollingEvery(Duration.ofMillis(250))
        .ignoring(StaleElementReferenceException.class);

String total = fluent.until(
        d -> d.findElement(By.id("cart-total")).getText()
);

Fix 6 — Re-locate after switching context

After switchTo().frame(), switchTo().window() or defaultContent(), don't reuse elements found in the previous context — find them again. See Alerts, Frames & Windows.

Fix 7 — Retry, but only as a last resort

If a component genuinely re-renders while you interact with it, a small, bounded retry is acceptable:

for (int attempt = 1; attempt <= 3; attempt++) {
    try {
        driver.findElement(By.className("product-name")).click();
        break;                                   // success
    } catch (StaleElementReferenceException e) {
        if (attempt == 3) throw e;               // don't swallow the final failure
    }
}

If you need retries all over your framework, the design — not the timing — is the problem.

The findElements() Loop Trap

The most common stale-element bug in real projects:

// ❌ Every click rebuilds the table, so every remaining reference goes stale
List<WebElement> rows =
        driver.findElements(By.cssSelector("table tr"));

for (WebElement row : rows) {
    row.click();
}

// ✅ Re-fetch the list on every iteration
int count =
        driver.findElements(By.cssSelector("table tr")).size();

for (int i = 0; i < count; i++) {
    driver.findElements(By.cssSelector("table tr"))
          .get(i)
          .click();
}

If each click navigates away, go back with driver.navigate().back() and wait for the table before the next iteration.

If you only need data, not clicks, read everything first: collect the texts into a List<String> in one pass, then work with the strings — strings never go stale.

What About PageFactory?

PageFactory's @FindBy fields are proxies: by default they look the element up again every time you use them, so they usually don't go stale. Two exceptions:

• @CacheLookup caches the element after the first lookup — never use it on elements that re-render.
• List<WebElement> you copy into a local variable — the copied elements are ordinary references and can go stale like any other.

Forgetting PageFactory.initElements() causes a different error — see NullPointerException with PageFactory.

Quick Diagnosis

Interview Answer

"StaleElementReferenceException occurs when a WebElement reference no longer points to a node in the current DOM — usually after a page refresh, an AJAX update, navigation or a JavaScript framework re-rendering the component. The element may still be visible, but my reference is to the old node. I fix it by locating elements immediately before use, storing By locators instead of WebElements in page objects, re-fetching lists inside loops, and using stalenessOf or refreshed() when I know the DOM will change. Retries are a last resort."

Add a real example — such as a product list rebuilt by a filter — and the answer stands out.

📚 Official documentation: Selenium docs: Understanding common errors · Selenium docs: Waiting strategies

👉 See also: WebDriverManager in Selenium:Setup,Examples & Best Practices

Frequently Asked Questions

What causes StaleElementReferenceException?

The stored WebElement no longer exists in the DOM because the page refreshed, the content was re-rendered, or you switched context.

How can I permanently fix it?

Locate elements immediately before interacting with them and store By locators — not WebElements — in page objects.

Will adding a wait always solve it?

No. A wait only helps with timing. If your reference is already stale, you must find the element again. stalenessOf and refreshed() help when you know the DOM will change.

Why does it happen when looping through findElements()?

The list holds references to the nodes at the moment it was built. If one interaction rebuilds the table, every remaining reference becomes invalid. Re-fetch the list on each iteration.

Is retry logic a good solution?

Only as a last resort, and always bounded. Frequent retries usually signal a design problem such as cached elements.

What is the difference between StaleElement and NoSuchElement?

NoSuchElementException means Selenium never found the element. StaleElementReferenceException means it found it earlier, but that node has since been removed or replaced.

Does Playwright have stale elements?

Not in the same way. Playwright locators are lazy — they find the element again every time you act on them — so re-rendering doesn't break stored locators. See The Complete Playwright Tutorial.

Related Tutorials

• Selenium Errors & Exceptions: The Complete Troubleshooting Guide
• Selenium Waits & Synchronization and the Wait Simulator
• Advanced Element Handling: Ajax & Hidden Elements
• Selenium Scenario-Based Interview Questions
• The Complete Selenium WebDriver Guide