Google's John Mueller: Bracketed and Percent-Encoded URLs Are Different URLs, So Pick One Form and Stick to It

Ras Al Khaimah, United Arab Emirates, 21 October 2026.

Google Search Advocate John Mueller said on 19 October 2026 that a URL containing raw square brackets and the same URL with those brackets percent-encoded are not equivalent, reversing what he said he had assumed and probably told people in the past. In a Bluesky thread replying to former Googler Vanessa Fox, Mueller pointed to the internet standard for URLs, RFC 3986, which treats brackets and plus signs as reserved characters. His advice: pick one form and use it consistently.

What was asked

Fox asked on 18 October whether Google treats an encoded URL as distinct from its unencoded form, giving the example of example.com/category?filter[]=123 in links versus example.com/category?filter%5B%5D=123 in canonical values. This pattern is common on ecommerce and faceted navigation sites, where frameworks generate array-style query parameters.

What Mueller said

• They are different URLs. Mueller wrote that he "would have assumed they're equivalent, but they're NOT", citing RFC 3986 section 2.2, which lists [ ] and + in the reserved set.
• Google may still merge them. If a server returns the same content for both, Google would crawl both versions and, on seeing the same content, de-duplicate them and pick one.
• Spaces and plus signs have the same problem. A space, a + and %20 are also handled differently, and the result depends on whether the character sits in the path or the query string.
• Hex case does not matter. Mueller said %5B and %5b are the same.
• Raw brackets are technically invalid. Under RFC 3986, [ and ] may only appear in the hostname to wrap IPv6 addresses. Browsers generally encode them when you type them, but code that requests a URL may send them as they are.

When Fox replied that a client site uses raw brackets throughout and indexes fine, Mueller said in a follow-up that he would expect it to keep working because much of the web is messy, but that he would not build a new site that way and would pay extra attention to keeping internal links, rel=canonical and structured data consistent. Fox added that she was seeing similar results for other characters, although Google appeared to treat ' and %27 as equivalent.

What the standard says

RFC 3986 states that URIs which differ only by replacing a reserved character with its percent-encoded form "are not equivalent". The same standard says the hexadecimal digits in a percent-encoding are case-insensitive, which is the basis for Mueller's point that %5B equals %5b. Google's own URL structure documentation already says Google Search supports URLs as defined by IETF STD 66 and that reserved characters "must be percent encoded".

Pair of URLs	Equivalent under RFC 3986?	Browser URL parser (WHATWG) treats as same string?
?filter[]=123 vs ?filter%5B%5D=123	No (reserved characters)	No
?x=%5B vs ?x=%5b	Yes (hex case is insensitive)	No (case is not normalised)
?q=a+b vs ?q=a%20b	No (+ is reserved)	No
?q=a b (raw space) vs ?q=a%20b	Raw space is not allowed	Yes (space is encoded to %20)

Our test shows why this trips people up. Running the comparison Mueller posted, new URL(...).href returns false for the bracket pair, as he said. It also returns false for %5B versus %5b, because the browser parser keeps the case as written even though the standard treats the two as equal. Any script that de-duplicates URLs with a plain string comparison will therefore see more distinct URLs than Google does in some cases, and fewer in others.

Context

Duplicate URL variants are an old crawl budget problem. Google's documentation on consolidating duplicate URLs says it chooses a canonical from signals including rel=canonical, redirects and sitemap inclusion, so mixed signals across encoded and unencoded forms make that choice less predictable. Mueller also noted that other crawlers, indexers and fetchers may be less exact than Google, which matters now that AI search tools fetch pages with their own code.

What to do

• Choose one form. If your platform generates bracketed parameters, decide on either the encoded or the raw form and output it everywhere: internal links, rel=canonical, hreflang, XML sitemaps and structured data.
• Prefer encoding for new builds. Google's documentation and Mueller both point to percent-encoding reserved characters.
• Check Search Console. Use URL Inspection on both forms of a sample URL to see which one Google selected as canonical.
• Audit your crawler settings. Make sure your own crawling and log analysis tools are not silently normalising or splitting these variants, so your reports match what search engines see.
• Do not rush a migration. For established sites that index well with raw brackets, Mueller's advice was consistency, not a wholesale URL change.

Conclusion

Mueller's correction is a small technical point with wide reach: an encoded and an unencoded URL can be two URLs to Google, and the search engine only merges them when it sees the same content. Sites using array-style parameters do not need to panic, since Google de-duplicates matching pages, but they should make every signal point at the same form.

Questions and answers

Does Google treat ?filter[]= and ?filter%5B%5D= as the same URL?

No. John Mueller said on 19 October 2026 that the two are not equivalent because RFC 3986 defines square brackets as reserved characters. Google would crawl both and de-duplicate them if the content is the same.

Does the case of percent-encoding matter to Google?

Mueller said hex case does not matter, so %5B and %5b are the same. RFC 3986 also says the hexadecimal digits in a percent-encoding are case-insensitive.

Should I change a site that already uses raw square brackets?

Mueller said he would expect such a site to keep working, but he would not set up a new site that way and would pay extra attention to keeping internal links, canonicals and structured data consistent.

What does Google's documentation say about reserved characters?

Google's URL structure documentation says Google Search supports URLs as defined by IETF STD 66 and that characters defined by the standard as reserved must be percent encoded.

###