%7D is a close curly brace
%7D is a close curly brace, usually the tail end of a JSON value that lost its matching open brace somewhere upstream.
| Character | "}" |
|---|---|
| Name | Close Curly Brace |
| Encoded | %7D |
| Reserved | No |
Why it breaks things
A close curly brace has no defined role in URL syntax, the same as %7B — outside RFC 3986's reserved and unreserved sets alike. In a path, browsers percent-encode a raw } automatically, verified: /report/}.pdf becomes /report/%7D.pdf on its own. In a query string, past the first ?, nothing touches it — a raw } sits exactly where it was typed.
That is where the trouble starts. JSON in a query value carries its own braces, and a bug that appends one closing brace too many — two hand-built filter fragments joined by concatenation instead of a proper merge, say — turns {"status":"open"} into {"status":"open"}}. The extra character survives the URL untouched either way, and only bites once the server decodes it and hands it to JSON.parse, which sees the object complete after the first } and rejects whatever follows.
The same failure runs in reverse: a cursor value copied from a wrapped terminal line can lose its opening { while keeping the closing } intact. What survives, something like "page":3,"after":"ORD-482"}, is not valid JSON, and no percent-encoding repairs it — %7D still means the same broken fragment. Encoding fixes how a value travels, not whether the JSON inside it is well-formed.
Real examples
Without encoding
https://example.com/tickets?filter={"status":"open"}}
With encoding
https://example.com/tickets?filter=%7B%22status%22%3A%22open%22%7D%7D
The raw value reaches the server unchanged either way — query braces are not touched by the browser. Percent-encoding does not fix the bug: both versions decode back to the same JSON with one extra }, and JSON.parse rejects both, because the object is already complete after the first }.
Without encoding
https://example.com/orders?cursor="page":3,"after":"ORD-482"}
With encoding
https://example.com/orders?cursor=%22page%22%3A3%2C%22after%22%3A%22ORD-482%22%7D
This cursor lost its opening { somewhere upstream — likely a copy-paste from a wrapped terminal line that started partway through. The value is legal in the URL, encoded or not; it is just not valid JSON, and no encoding can put the missing { back.
Decode something
Result
Breakdown
| Part | Value | Copy |
|---|
History
Nothing yet.
History stays in this browser. It is never sent to our server.
Common questions
- Why does my JSON query parameter fail even though the URL loads fine?
- The URL layer and the JSON layer are separate. A URL can carry any text in a query value, brace imbalance included, without complaint. JSON.parse is stricter — it needs every { matched by a } in the right order, and rejects the value the moment that is not true.
- Does percent-encoding a JSON value fix a missing or extra brace?
- No. Percent-encoding only changes how the value travels through the URL. Decode it back and you have exactly the same JSON text you started with, imbalance and all.
- Is %7D the same kind of problem as %7B?
- They are the same character family — neither has a defined URL meaning — but the usual failure differs. %7B is most often a template placeholder nobody filled in. %7D is more often a brace count gone wrong somewhere in how a JSON value was built or copied.
- Why did copying a long URL from my terminal give me a broken request?
- Wrapped lines in a terminal are easy to select from the wrong point. If the value contains JSON, grabbing the second half only keeps the closing brace, dropping the opening one and everything it was supposed to match.