Google Treats Raw and Encoded Bracket URLs as Different URLs

Google Search Advocate John Mueller confirmed on Bluesky Monday that a raw square bracket in a URL and its percent-encoded form, %5B and %5D, are different URLs — and admitted he may have given wrong advice before. "I probably gave people the wrong answer on this in the past," he wrote, noting he would have assumed the two forms were equivalent.

Google will crawl both versions, Mueller said. If it finds identical content — "maybe even checksum level" — it will de-dupe them and pick one. His full words: "We'd crawl both versions, if we see the same content (maybe even checksum level), we'd de-dupe them and pick one." The same rules apply to spaces, plus signs, and %20.

Why the two forms are not equivalent

Mueller traced the distinction to RFC 3986, the internet standard for URI syntax. Section 2.2 places brackets and plus signs in its reserved character set, meaning URIs that swap a reserved character for its percent-encoded version "are not equivalent."

The exchange started with Vanessa Fox, an ex-Google employee who built Google's Webmaster Central. She asked — first in comments on the initial Non-Canonical Cabinet episode, then in a Bluesky reply — whether Google treats the encoded form as a different URL. Her examples: ?filter[]=123 and ?filter%5B%5D=123. A JavaScript comparison of the two returned false.

Mueller added that raw brackets in a query string are technically invalid under RFC 3986, which reserves brackets for the hostname, specifically to wrap raw IPv6 addresses. Letter case in encoding doesn't matter: "%5B" and "%5b" are equivalent, following the standard's hex character rules.

What should site owners do?

Pick one format and use it everywhere — links, canonical tags, sitemaps, and structured data. Mueller's recommendation is blunt: "always encode it, never show []."

Google's own URL structure documentation already aligns with this. It states Google Search supports URLs as defined by IETF STD 66 (the standard containing RFC 3986) and that "Characters defined by the standard as reserved must be percent encoded."

Browsers complicate matters slightly. A browser may encode brackets before sending a request from the URL bar, while JavaScript or other code requesting a bracketed URL might send the brackets as-is. That's another reason to standardize.

What about sites already using raw brackets?

Fox said she was thinking of a site that uses invalid bracket notation throughout, indexes fine, and stays unchanged because converting would be too much trouble. Mueller said he wouldn't expect problems from that structure but "wouldn't set up a new site like this." He advised paying extra attention to internal links, rel=canonical metadata, and structured data so they're uniform.

He also flagged a broader risk: based on problems Google encountered with these characters over 10+ years ago, other crawl, indexer, and fetch programs may not be "as exact in this logic" when processing bracketed URLs. He didn't name which tools might struggle.

Why this matters

If multiple URL versions carry the same content, Google picks one. If every URL on your site uses the same format, that choice is more likely to land your way. Mueller expects existing sites with raw brackets to keep working — the practical task is making internal links and metadata point to a single version. He also suggested checking whichever crawlers and fetchers matter to you for how they handle bracketed URLs.

Google had not yet posted the second Non-Canonical Cabinet video, on robots.txt, as of October 20th.