The ID exists, but your CSS selector changes what it means

The element is plainly present in DevTools, but Selenium reports an invalid selector when the test builds #order:42.7. The ID is legal HTML. The bug is that raw attribute text was inserted into a different language, CSS, where the colon and dot are syntax.

Why the ID and the selector follow different grammars

An HTML id value may contain characters that are not valid unescaped CSS identifier characters. A browser can retrieve id="123item" with getElementById("123item"), yet querySelector("#123item") rejects the selector because an unescaped CSS identifier cannot begin with a digit. Both results are correct.

Punctuation changes meaning too:

• #account:edit asks CSS for ID account plus a pseudo-class named edit.
• #invoice.total asks for ID invoice and class total.
• #customer>name asks for a name child of the element with ID customer.
• #panel[old] includes an attribute selector.
• A quote or backslash can break an attribute-selector string assembled by concatenation.

Depending on the value, Selenium may throw InvalidSelectorException, return no elements, or match the wrong element. The last outcome is the most dangerous because the locator appears valid and the failure moves to a later assertion.

Escaping is contextual. CSS identifier escaping, CSS string escaping, XPath string quoting, Java string escaping, and URL encoding solve different problems. Adding a backslash wherever a test happens to fail is not a durable algorithm. Leading digits, null characters, hexadecimal escapes followed by digits, and backslashes all have edge cases that hand-written replacements usually miss.

The first design question is simpler: do you need CSS at all? If the dynamic value is the complete ID, Selenium already provides an exact ID locator.

Use an ID locator for an exact ID value

By.id(rawId) states the intent without mixing the value with selector syntax. Selenium's Java API defines the argument as the value of the id attribute to search for. Let the binding handle how that lookup is represented to the browser.

This runnable JUnit 5 example covers an ID with a colon and dot, an ID that starts with a number, and a descendant search that avoids building a combined selector:

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

import java.nio.charset.StandardCharsets;
import java.util.Base64;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.InvalidSelectorException;
import org.openqa.selenium.JavascriptExecutor;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;

class DynamicIdSelectorTest {
    private final WebDriver driver = new ChromeDriver();

    @AfterEach
    void stopBrowser() {
        driver.quit();
    }

    @Test
    void locatesSpecialCharacterIdsWithoutHandWrittenEscapes() {
        String html = """
            <section id="order:42.7">
              <button class="pay"><span class="label">Pay now</span></button>
            </section>
            <p id="123item">Numeric prefix</p>
            """;
        String page = "data:text/html;base64," + Base64.getEncoder()
            .encodeToString(html.getBytes(StandardCharsets.UTF_8));
        driver.get(page);

        String rawId = "order:42.7";
        WebElement order = driver.findElement(By.id(rawId));
        WebElement label = order.findElement(By.cssSelector(".pay .label"));
        assertEquals("Pay now", label.getText());

        String escaped = (String) ((JavascriptExecutor) driver)
            .executeScript("return CSS.escape(arguments[0]);", rawId);
        WebElement sameOrder = driver.findElement(
            By.cssSelector("#" + escaped)
        );
        assertEquals(rawId, sameOrder.getAttribute("id"));

        assertEquals(
            "Numeric prefix",
            driver.findElement(By.id("123item")).getText()
        );
        assertThrows(
            InvalidSelectorException.class,
            () -> driver.findElement(By.cssSelector("#123item"))
        );
    }
}

Scoping a second search from the order element is often the best answer for #dynamic-id .pay .label. It avoids an extra JavaScript command and keeps the dynamic value out of CSS. The trade-off is two WebDriver find commands instead of one, which matters on a high-latency remote Grid. In most suites, locator clarity is worth that small cost.

Run the example without shortening the selector exception:

mvn -Dtest=DynamicIdSelectorTest#locatesSpecialCharacterIdsWithoutHandWrittenEscapes \
  -DtrimStackTrace=false test

Escape only the dynamic identifier fragment

Sometimes CSS composition is genuinely useful. A test may need a pseudo-class, sibling relationship, or selector list that cannot be expressed by searching inside a container. In that case, use the platform's CSS.escape() function on the untrusted identifier value and preserve the static selector syntax:

String escapedId = (String) ((JavascriptExecutor) driver)
    .executeScript("return CSS.escape(arguments[0]);", rawId);

By saveButton = By.cssSelector("#" + escapedId + " > button.save");
driver.findElement(saveButton).click();

CSS.escape() returns text suitable for use as a CSS identifier fragment. For order:42.7, it escapes the colon and dot. For an ID beginning with a digit, it produces the required numeric escape. It also handles cases that a replace(":", "\\:") helper never considered.

Do not pass the whole selector to CSS.escape():

// Wrong: this escapes #, >, dots, and spaces that should remain CSS syntax.
String broken = (String) ((JavascriptExecutor) driver)
    .executeScript("return CSS.escape(arguments[0]);", "#" + rawId + " > button.save");

The boundary is the key. Static selector operators belong to the test. Runtime ID text is data and must be escaped before insertion.

Calling the browser to escape each value adds a remote round trip and requires a live browsing context. A carefully maintained Java implementation of the CSSOM escaping algorithm can remove that cost, but it also becomes code your team must test against punctuation, leading digits, control characters, Unicode, and null input behavior. Do not publish a three-line replacement as if it implements the standard.

If selector composition is common, put it behind one narrowly named helper such as a locator for a descendant of an exact ID. Test the helper with IDs containing a colon, dot, question mark, leading digit, backslash, quote, and non-ASCII text. Each case should assert the exact returned element ID, not merely that some element matched. Centralization costs a utility and its tests, but it prevents five page objects from developing five incompatible escape rules.

Keep that helper responsible for one grammar boundary. It should accept raw ID data plus a separate static descendant selector, rather than accepting an arbitrary partly assembled string. A single string parameter makes it impossible to know which characters are data and which are intended CSS operators.

An exact attribute selector is not a shortcut for arbitrary values:

By risky = By.cssSelector("[id='" + rawId + "']");

Colons and dots lose their special meaning inside the quoted attribute value, so this appears to work for many IDs. A single quote or backslash in rawId changes the CSS string, however. Use By.id() for exact lookup, or apply a correct CSS string-escaping routine when an attribute selector is truly required.

Separate selector syntax from element timing

Capture the raw ID and the final selector as separate fields. Without both, CI logs often show a plausible selector but hide which value produced it. Do not log IDs that contain customer data or secrets; use a hash or a redacted representation when the identifier is sensitive.

Then test the two layers in the browser console:

const rawId = "order:42.7";
document.getElementById(rawId);                    // HTML ID lookup
document.querySelector(`#${rawId}`);              // invalid or misinterpreted
document.querySelector(`#${CSS.escape(rawId)}`);  // escaped CSS lookup

The outcomes lead to different fixes:

• getElementById() returns null: the value is wrong, the element is not present yet, or the current frame or shadow context is wrong. Escaping cannot help.
• The raw querySelector() throws a syntax error while the escaped form succeeds: the failure is CSS grammar.
• Both selectors are valid but the raw form returns the wrong node: punctuation changed the selector's meaning.
• The escaped selector returns several nodes: the page violates ID uniqueness, or the search spans a context with malformed markup. Escaping does not create uniqueness.
• The escaped selector works locally but not in CI: compare the actual raw value and DOM, not only browser versions.

An invalid selector fails during parsing. Waiting longer is pointless because the same string will remain invalid. By contrast, a valid escaped selector that currently finds nothing may need a wait if the product creates that exact element asynchronously.

Keep the failure type intact. Catching InvalidSelectorException and converting it to NoSuchElementException erases the distinction between broken test syntax and missing application state. That distinction tells a reviewer whether to inspect the locator builder or the page lifecycle.

Be careful when copying an escaped selector from logs. Java string rendering, JSON, terminal output, and CSS each give backslashes meaning, so a line that appears to contain one slash may have passed through several encoders. Log the raw ID and final selector as separate structured fields, then reproduce through CSS.escape() in the browser instead of adding another slash by sight.

Prefer a stable identity over clever escaping

Some IDs are syntactically awkward but stable, such as server-generated component IDs containing colons. By.id() or correct escaping is appropriate there. Other IDs include a fresh random token on every render. No escape function makes those values predictable.

Ask the product team for a stable automation contract when the test otherwise scrapes a runtime ID from unrelated markup. A dedicated data-testid, a unique accessible role and name, or a stable component relationship usually communicates intent better than prefix and substring matching.

That contract has a cost. Test attributes must be reviewed and maintained, and accessible locators can change when product wording changes. Dynamic-ID prefix selectors also have a cost: they can match multiple instances, silently select stale components, and tie the test to an implementation detail. Choose the cost the team can see and govern.

If the ID comes from the application response that created the record, exact lookup may be the right user journey. Keep the raw value as data and locate it with By.id(). If the test is discovering the value by parsing another selector only to construct a second selector, simplify the flow before adding an escaping utility.

When escaping is not the fix

Do not apply CSS escaping to XPath. XPath literals have their own quoting rules, and CSS.escape() output changes the value XPath tries to match. Switching selector languages without understanding their data boundary only moves the bug.

Do not escape a static locator that is already invalid. Correct the locator at its source and cover it with a focused component test. Runtime escaping is for runtime data, not for concealing mistakes in checked-in selector syntax.

Avoid partial ID selectors such as [id^='order:'] merely because the suffix is inconvenient. Prefixes can match old dialogs, hidden templates, or two records at once. If a partial match reflects a real stable contract, assert uniqueness before interacting.

Escaping also cannot cross browsing contexts. A correct selector still finds nothing when the element is inside an iframe and Selenium has not switched to it, or when the search must begin from a shadow root. Diagnose search context separately from grammar.

Finally, do not celebrate when an escaped locator finds an element but the business assertion targets the wrong record. Verify the matched element's exact id and its owning component while introducing the fix. Selector validity is only the first claim; correct identity is the one the test needs.