%24 is a dollar sign
%24 is a dollar sign, legal raw in a URL but given special meaning by query languages like MongoDB's and OData's.
| Character | "$" |
|---|---|
| Name | Dollar Sign |
| Encoded | %24 |
| Reserved | Yes — it has a special meaning in a URL |
Why it breaks things
A dollar sign is an RFC 3986 sub-delimiter, with no fixed meaning in the generic URL syntax — nothing stops a raw $ from reaching a server intact. Specific query languages give it a job anyway. MongoDB's operators are named with a leading $, like $gt and $ne; OData's query options do the same, as $filter and $top. In both, the character is how the API tells an operator apart from an ordinary field.
That makes an unencoded $ risky wherever a value might be mistaken for one of those operators. An API expecting $filter as a fixed keyword handles this safely, but a value passed unvalidated into a MongoDB query, containing a stray $gt or $where, can be read as an operator instead of plain text — a known category of query injection.
The other failure has nothing to do with any API and everything to do with where the URL is typed. In an unquoted or double-quoted shell command, $ starts variable expansion — http://example.com/search?q=$gt loses the $gt entirely if no shell variable named gt is set, since bash silently substitutes an empty string rather than erroring. Only single quotes around the whole URL stop this; double quotes do not.
Real examples
Without encoding
https://example.com/api/users?filter=$gt:100
With encoding
https://example.com/api/users?filter=%24gt%3A100
The raw value reaches the server fine — $ has no meaning to the URL layer itself. The risk is in whatever reads it afterward: if this value is passed into a MongoDB-style query without validation, $gt can be read as a query operator instead of a literal piece of text.
Without encoding
https://example.com/search?q=$gt
With encoding
https://example.com/search?q=%24gt
Paste this into an unquoted or double-quoted bash command and $gt is read as a variable reference, not literal text. With no variable named gt set, bash silently substitutes an empty string, so the request goes out as q= with nothing after it — no error, just a silently wrong URL.
Decode something
Result
Breakdown
| Part | Value | Copy |
|---|
History
Nothing yet.
History stays in this browser. It is never sent to our server.
Common questions
- Do I need to percent-encode a dollar sign in an ordinary URL?
- Not for the URL itself — it is a legal sub-delimiter and travels through a browser or server unchanged. Encoding it matters once the value reaches a specific query language, like MongoDB's or OData's, that gives $ a special meaning.
- Why did part of my URL disappear when I ran it from the terminal?
- An unquoted or double-quoted $ in a shell command starts variable expansion. If the text after it does not match a real variable name, bash quietly replaces it with nothing, rather than failing loudly. Wrapping the whole URL in single quotes stops this.
- Is a $ in a query string ever dangerous on its own?
- Only in context. It becomes a risk when a value containing it is passed unvalidated into a system, like MongoDB, that treats a leading $ as an operator name rather than as literal data — that is a known class of query injection, separate from anything the URL standard governs.
- Does double-quoting a URL in bash protect the dollar sign?
- No. Double quotes stop many shell characters from being special, but $ still triggers variable expansion inside them. Single quotes are the only reliable way to keep a $ in a URL literal on the command line.