How to Handle StaleElementReferenceException in Selenium

When working with Selenium WebDriver, one of the most common problems automation testers encounter is StaleElementReferenceException in Selenium. A test may locate an element successfully, but when Selenium tries to interact with that same element a few moments later, the test suddenly fails.

This usually happens because the web page has changed after Selenium originally located the element. Modern websites frequently update parts of the DOM dynamically, reload components, or replace existing elements without refreshing the entire page.

Understanding why stale elements occur and learning how to handle them correctly can make Selenium tests more stable, readable, and maintainable.

In this guide, we will explain what StaleElementReferenceException means, why it occurs, how to fix it, and which practices can help reduce stale element problems in automated browser testing.

What Is StaleElementReferenceException in Selenium?

Selenium interacts with elements by locating them in the Document Object Model, commonly called the DOM.

For example, a test may locate a button:

WebElement button = driver.findElement(By.id("submit-button"));

At that moment, Selenium keeps a reference to the element it found.

However, imagine that JavaScript updates the page before Selenium clicks the button. The original element may be removed from the DOM and replaced by a new element that looks exactly the same.

If Selenium then tries to use the original reference:

button.click();

the reference may no longer point to a valid element.

Selenium can then throw a StaleElementReferenceException.

In simple terms, the exception means:

Selenium found the element earlier, but that specific element is no longer attached to the current DOM.

Why Does StaleElementReferenceException Occur?

There are several common situations that can make an element stale.

Understanding the cause is important because simply retrying every failed interaction is not always the best solution.

1. The Page Refreshes

A full page refresh creates a new DOM.

Any element references stored before the refresh can become invalid.

For example:

WebElement loginButton = driver.findElement(By.id("login"));

driver.navigate().refresh();

loginButton.click();

The loginButton reference was created before the refresh. After the refresh, Selenium should locate the button again.

A better approach would be:

driver.navigate().refresh();

WebElement loginButton = driver.findElement(By.id("login"));
loginButton.click();

The important principle is simple: locate the element after the page has changed.

2. JavaScript Updates the DOM

Modern websites often update content without refreshing the full page.

Frameworks and JavaScript-based interfaces may:

  • Replace table rows
  • Update product cards
  • Reload search results
  • Replace buttons
  • Render new form components
  • Update navigation elements
  • Refresh parts of dashboards

An element can therefore disappear and be recreated in a fraction of a second.

From a user’s perspective, the page may look almost identical. From Selenium’s perspective, however, the old element and the new element are different DOM objects.

3. The User Navigates to Another Page

If a test finds an element and then navigates somewhere else, the original element reference normally becomes irrelevant.

For example:

WebElement menu = driver.findElement(By.id("main-menu"));

driver.get("https://example.com/another-page");

menu.click();

The stored element belongs to the previous document.

After navigation, Selenium should locate elements from the current page again.

4. An iFrame Reloads

Elements located inside an iFrame can also become stale when the frame content reloads or changes.

In this situation, you may need to:

  1. Switch to the correct frame again.
  2. Locate the element again.
  3. Perform the interaction.

Handling frames correctly is an important Selenium skill because frame changes can easily cause element references to become invalid.

Selenium Academy’s Selenium curriculum includes topics such as Selenium WebDriver, identifying elements, waiting, element interaction, windows, tabs and iFrames, and avoiding flaky Selenium tests. You can explore the Selenium course catalog for the available Selenium training topics.

5. Lists or Tables Are Dynamically Updated

Dynamic tables are another common source of stale element errors.

Consider this example:

List<WebElement> rows = driver.findElements(By.cssSelector("table tbody tr"));

If the table updates after Selenium creates the list, some or all of those WebElement references may become stale.

This is especially common with:

  • Search results
  • Pagination
  • Sorting
  • Filtering
  • Live dashboards
  • Infinite scrolling
  • AJAX-based tables

Instead of keeping old references for too long, consider locating the required elements again after each major DOM update.

How to Fix StaleElementReferenceException in Selenium

There is no single fix for every stale element problem.

The correct approach depends on why the DOM is changing.

However, several techniques are particularly useful.

Re-Locate the Element

The simplest solution is often to locate the element again immediately before interacting with it.

Instead of:

WebElement button = driver.findElement(By.id("save"));

someActionThatChangesThePage();

button.click();

use:

someActionThatChangesThePage();

WebElement button = driver.findElement(By.id("save"));
button.click();

This gives Selenium a fresh reference to the current DOM element.

Re-locating elements is especially helpful when you know that an action triggers a page update.

Use Explicit Waits

Timing problems frequently contribute to stale element failures.

A test may try to interact with an element while the page is still changing.

Explicit waits allow Selenium to wait for a particular condition before continuing.

For example:

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

WebElement button = wait.until(
    ExpectedConditions.elementToBeClickable(By.id("submit-button"))
);

button.click();

This approach is generally more reliable than immediately locating an element and assuming that the page has finished updating.

Selenium Academy specifically includes Selenium Waiting as part of its Selenium curriculum, alongside element interaction and techniques for avoiding flaky Selenium tests.

If you are building your Selenium fundamentals, the Selenium Academy Selenium catalog provides training topics covering these areas.

Wait for an Old Element to Become Stale

Sometimes you know that an existing element will be replaced.

In that situation, you can explicitly wait until Selenium confirms that the old element has become stale.

For example:

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

driver.findElement(By.id("refresh")).click();

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.stalenessOf(oldElement));

After that, locate the replacement:

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

This technique is useful when a page intentionally replaces a component after an action.

Use refreshed() with Expected Conditions

Selenium’s expected conditions can also help when an element is refreshed during a DOM update.

For example:

WebElement element = wait.until(
    ExpectedConditions.refreshed(
        ExpectedConditions.elementToBeClickable(By.id("save"))
    )
);

The goal is to obtain an element that matches the expected condition after the page updates.

However, this should still be used with an understanding of what is causing the DOM change rather than as a universal solution to every stale element error.

Avoid Holding WebElement References for Too Long

One useful design principle is to avoid storing dynamic WebElement objects for longer than necessary.

Suppose your page contains a frequently updated shopping cart.

Instead of locating the checkout button once at the start of a long test and using the same reference later, locate it close to the point where it will actually be used.

For example:

driver.findElement(By.id("checkout")).click();

may be more reliable than keeping an old WebElement reference while multiple page updates occur.

This becomes increasingly important for modern applications where the DOM can change frequently.

Retry Carefully

A retry mechanism can sometimes help.

For example:

for (int i = 0; i < 3; i++) {
    try {
        driver.findElement(By.id("submit")).click();
        break;
    } catch (StaleElementReferenceException e) {
        // Try locating the element again
    }
}

However, retries should be used carefully.

If every stale element problem is automatically retried without understanding the cause, the test suite may hide genuine application or synchronization problems.

A better approach is:

  • Understand why the element becomes stale.
  • Synchronize the test properly.
  • Re-locate the element when required.
  • Use retries only where temporary DOM replacement is expected.

Avoid Using Thread.sleep() as the Main Solution

A common reaction to unstable Selenium tests is to add a fixed delay:

Thread.sleep(5000);

This may appear to solve the problem temporarily, but it has several disadvantages.

The page might finish updating in 500 milliseconds, meaning the test wastes time.

Or the page could take longer than five seconds, causing the test to fail anyway.

Explicit waits are usually more flexible because they wait for a specific condition instead of blindly pausing for a fixed amount of time.

Handle Dynamic Lists Carefully

Consider a list of products:

List<WebElement> products =
    driver.findElements(By.cssSelector(".product"));

If clicking one product causes the product list to refresh, continuing to use the original products collection can produce stale references.

Instead, consider re-locating the list:

for (int i = 0; i < 5; i++) {

    List<WebElement> products =
        driver.findElements(By.cssSelector(".product"));

    products.get(i).click();

    // Perform required action and return
}

The exact implementation depends on the application, but the general principle remains the same:

Do not assume a WebElement reference is still valid after the DOM changes.

StaleElementReferenceException and Flaky Selenium Tests

Stale element errors can also contribute to flaky automated tests.

A flaky test may:

  • Pass during one run
  • Fail during another
  • Pass again without any code change

Dynamic DOM updates and poor synchronization are common reasons for inconsistent Selenium behavior.

Reducing unnecessary stale element errors can therefore improve overall test reliability.

Good Selenium tests should synchronize with the application rather than depend on accidental timing.

This means focusing on:

  • Appropriate waits
  • Reliable locators
  • Fresh element references
  • Clear test flows
  • Predictable page state
  • Proper frame and window handling

The Selenium Academy curriculum includes a dedicated topic on Avoiding Flaky Selenium Tests, as well as Selenium waits, element identification, validation, design patterns, and cross-browser Selenium testing.

You can see the complete curriculum through the Selenium Academy Selenium course.

Stale Elements and the Page Object Model

Test architecture can also influence how stale references are handled.

When using a Page Object Model or another Selenium design pattern, it is generally useful to design page interactions so elements can be located when they are actually needed.

For example, instead of exposing a long-lived element reference:

WebElement saveButton;

a page method can locate the element at interaction time:

public void clickSaveButton() {
    driver.findElement(By.id("save")).click();
}

Another approach is to store the locator:

private By saveButton = By.id("save");

public void clickSaveButton() {
    driver.findElement(saveButton).click();
}

This can make re-locating dynamic elements easier.

The important point is not that one design solves every stale element problem. The goal is to avoid unnecessary dependence on outdated DOM references.

Selenium Academy also includes Selenium Design Pattern as a curriculum topic.

Common Mistakes When Fixing StaleElementReferenceException

Catching the Exception Everywhere

Catching StaleElementReferenceException throughout the test suite can make failures harder to understand.

Use exception handling where stale elements are genuinely expected rather than hiding every failure.

Adding Long Fixed Sleeps

Long pauses can slow down the entire test suite without guaranteeing reliability.

Use condition-based waits whenever possible.

Reusing Elements After Page Navigation

If the page changes substantially, assume old references may no longer be valid.

Locate the required elements from the current DOM.

Ignoring the Real Cause

A stale element exception is often a symptom.

The underlying cause may be:

  • Dynamic rendering
  • JavaScript updates
  • Navigation
  • Frame changes
  • Table refreshes
  • Incorrect synchronization

Finding the cause usually leads to a better solution than simply retrying the interaction.

Best Practices for Preventing Stale Element Errors

To reduce StaleElementReferenceException in Selenium tests:

  • Locate dynamic elements close to the point of interaction.
  • Re-locate elements after page or component refreshes.
  • Use explicit waits for meaningful conditions.
  • Avoid relying on fixed sleep() delays.
  • Do not keep dynamic WebElement references longer than necessary.
  • Handle iFrame changes carefully.
  • Expect tables and lists to be replaced after sorting or filtering.
  • Use stable locators.
  • Design Page Objects with dynamic applications in mind.
  • Investigate repeated stale element failures instead of simply hiding them with retries.

These practices can make automated tests easier to maintain as the application evolves.

Example: A More Reliable Selenium Interaction

Consider a search results page.

A user enters a search term, and JavaScript refreshes the results.

A fragile test might look like:

WebElement firstResult =
    driver.findElement(By.cssSelector(".search-result"));

driver.findElement(By.id("search")).sendKeys("Selenium");
driver.findElement(By.id("search-button")).click();

firstResult.click();

The firstResult reference was captured before the new results were loaded.

A better approach is:

driver.findElement(By.id("search")).sendKeys("Selenium");
driver.findElement(By.id("search-button")).click();

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

WebElement firstResult = wait.until(
    ExpectedConditions.elementToBeClickable(
        By.cssSelector(".search-result")
    )
);

firstResult.click();

The test now waits for the current search result and obtains a fresh reference after the page update.

This illustrates one of the most important lessons for handling stale elements: synchronize with the current state of the application.

Learn Selenium WebDriver Step by Step

Handling exceptions becomes easier when you understand how Selenium locates elements, interacts with the DOM, and waits for browser conditions.

Selenium Academy provides Selenium training covering Selenium WebDriver, element identification, element interaction, waits, validation, screenshots, design patterns, flaky test prevention, cross-browser testing, Selenium Grid, and CI-related topics. The Selenium course supports Java, C#, Ruby, Python, and JavaScript.

You can explore the Selenium Academy Selenium course catalog to see the available training topics.

For learners interested in both browser and mobile automation, Selenium Academy also offers an Appium course catalog.

Available learning packages can be reviewed on the Selenium Academy pricing page.

Conclusion

StaleElementReferenceException in Selenium occurs when Selenium attempts to interact with an element reference that is no longer attached to the current DOM.

The most effective solution is not simply to catch the exception repeatedly. Instead, understand why the page changed, re-locate elements when necessary, and synchronize tests with explicit waits and predictable application states.

By managing dynamic elements carefully and avoiding outdated references, you can reduce flaky failures and create more reliable Selenium automation.

Developers and testers who want to strengthen their knowledge of Selenium WebDriver, waits, element interaction, design patterns, and flaky test prevention can explore the Selenium Academy learning platform.

Frequently Asked Questions

What causes StaleElementReferenceException in Selenium?

StaleElementReferenceException usually occurs when Selenium stores a reference to an element and that element is later removed, replaced, or disconnected from the current DOM. Page refreshes, JavaScript updates, navigation, and dynamic components are common causes.

How do I fix StaleElementReferenceException in Selenium?

Common approaches include re-locating the element, using explicit waits, waiting for an old element to become stale, and locating dynamic elements close to the point where they are used.

Does Thread.sleep fix StaleElementReferenceException?

A fixed delay may occasionally appear to solve timing-related failures, but it does not guarantee that the correct element is available. Condition-based explicit waits are generally more suitable for synchronizing Selenium tests with dynamic pages.

Should I retry after StaleElementReferenceException?

Retrying may be appropriate when an application is expected to replace an element temporarily. However, repeated retries should not be used to hide synchronization or locator problems.

Can dynamic websites cause stale elements?

Yes. Websites that update sections of the DOM dynamically can replace elements without performing a full page refresh. Previously stored Selenium element references can therefore become stale.

How can I reduce flaky Selenium tests?

Use reliable locators, appropriate explicit waits, fresh element references, predictable page states, and clear test design. Selenium Academy’s curriculum also includes dedicated training on avoiding flaky Selenium tests.