%2A is an asterisk

%2A is an asterisk, legal raw in a URL and commonly used as a wildcard in search and field-selection values.

Character"*"
NameAsterisk
Encoded%2A
ReservedYes — it has a special meaning in a URL

Why it breaks things

An asterisk is an RFC 3986 sub-delimiter, with no fixed meaning in the generic syntax, though plenty of APIs give it one anyway. A search box that accepts wildcard*, or an endpoint offering fields=* to request every field, both lean on * as an informal stand-in for "match anything" — borrowed from shell globbing and SQL LIKE patterns, not something the URL standard defines.

JavaScript treats it as safe by default: verified, encodeURIComponent("*") and encodeURI("*") both return * unchanged. That puts it in the same small group as ! ~ and the parentheses — characters the language's built-in encoders leave exactly as typed, on the assumption a URL can carry them literally without issue.

That assumption does not hold everywhere. A router matches an incoming request path against a route pattern the developer wrote — if a wildcard exists, it lives in that pattern, not in the request. A literal asterisk arriving as part of a request's own data is just data being compared against the pattern, not a wildcard being reinterpreted. What can still reject the request is a layer sitting in front of routing entirely: a gateway, reverse proxy, or web application firewall applying a character filter that blocks certain characters, asterisk included, in a path segment, before the request ever reaches route matching. A value containing a real asterisk can be rejected there, well before your own routing code runs. OpenAPI's own path templating does not use * at all — it names a path parameter with {param} — so there is no OpenAPI wildcard for the value to be confused with either.

Real examples

Without encoding

https://example.com/search?q=vitamin*

With encoding

https://example.com/search?q=vitamin%2A

The raw asterisk reaches the server unchanged — a search box built to treat it as a wildcard reads this exactly as intended. Encoding it is unnecessary for that case, and would only matter if this value were later reused somewhere * has a different, stricter meaning.

Without encoding

https://api.example.com/v1/products/vitamin*d/details

With encoding

https://api.example.com/v1/products/vitamin%2Ad/details

Some API gateways, reverse proxies, and web application firewalls apply a character filter that blocks a literal * in a path segment, rejecting the request before it reaches routing at all — not because anything reinterprets it as a wildcard pattern, but because the character itself is on a blocklist. Encoding it as %2A avoids that filter and keeps the value ordinary data all the way through.

Decode something

History

    Nothing yet.

    History stays in this browser. It is never sent to our server.

    Common questions

    Do I need to percent-encode an asterisk in a search query?
    Usually not. Most search endpoints that support wildcards expect a raw * and read it as intended. Encoding matters more once the value moves through infrastructure — like an API gateway or router — that gives * a routing meaning of its own.
    Why does encodeURIComponent leave my asterisk alone?
    JavaScript's built-in encoders treat * as one of a small set of characters assumed safe to write literally in a URL, the same group that includes ! ~ and the parentheses. This is deliberate, matching characters the URL standard itself never requires encoding.
    Why did my API reject a product code with an asterisk in it?
    Usually a gateway, reverse proxy, or web application firewall in front of your application, applying a character filter that blocks certain characters — asterisk included — in a path segment. It is not your router reinterpreting the value as a wildcard pattern; the character is rejected before routing even runs. If your value might contain a real asterisk, percent-encoding it as %2A avoids that filter.
    Is fields=* a standard part of URLs?
    No. It is a convention some APIs use to mean "return every field," not something RFC 3986 defines. Whether an endpoint supports it, and what a literal asterisk means there, depends entirely on that API's own documentation.