Hi @ODY90, as far as I'm aware curly brackets are not considered valid in URLs and must be url-encoded (see RFC3986)

I am not good in RFC's =) But after a quick search, I found nothing regarding curly braces. Moreover, square brackets are in the list of reserved characters, but they are allowed in regular expressions and browsers processed as well.
Latest chrome processed curly braces without encoding. But some difference exist with curl

curl "https://www.google.com/search?q=%7Bprice%7D" -o search1.html

Gives {price} in search field, but

curl "https://www.google.com/search?q={price}" -o search2.html

Gives price in search field
I assume chrome might be cheating and encode somewhere under the hood.

Oh, find more interesting)

curl "https://www.google.com/search?q=[price]" -o search5.html
curl: (3) bad range in URL position 34:
https://www.google.com/search?q=[price]
                                 ^

But

curl -g "https://www.google.com/search?q=[price]" -o search5.html

works well and pass brackets to input, the same with curly braces.
Sorry for long story, but as for me, curly braces is a valid symbol in query part of url.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Friendly reminder that this issue exists. If I don't hear anything I'll close this.

Be careful that the curl tool has some special globbing features (the bad range in URL position 34 error comes from that feature), which involves both curly and square brackets (this is why the non-encoded {} around price disappear, as it is treated as a glob alternative with a single choice). You should use the --globoff (short -g) to test how the webserver behaves for them.

I assume chrome might be cheating and encode somewhere under the hood.

That comment looks weird to me. You were testing with curl, not with chrome