Query String Parsing vs URL Encoding
Separate URL query-parameter parsing from percent encoding, plus-as-space rules, and full-URL handling boundaries.
Parsing handles parameter structure
Parsing focuses on ?, &, and =. With ?q=a%2Bb+c&tag=one&tag=two, it produces q=a+b c and two ordered tag rows. A URI such as mailto:ops@example.com has a scheme but no query, so it produces no parameters rather than one synthetic key.
Encoding handles character representation
URL encoding focuses on whether characters can safely appear in a URL component, such as spaces, non-ASCII text, &, =, and #. When handling a full URL, do not encode the protocol, slashes, and separators as one block; usually encode individual parameter values.
0Failure and review boundaries
A lone % or incomplete escape must fail instead of being guessed. Parsing and encoding do not prove that a destination exists or is safe, and decoding the whole URL before splitting can turn encoded separators into structural ones. Preserve the serialized source for comparison.
FAQ
About this topic
Should I parse first or URL-decode first?
Usually parse the Query String structure first, then inspect decoded keys and values. Decoding an entire URL too early can break separator meaning.
Can URL encoding hide sensitive data?
No. URL encoding is a public reversible representation, not encryption. Do not use it to hide tokens, passwords, or personal data.
Do plus signs and %20 both mean spaces?
In this query parser, + becomes a space, %20 also becomes a space, and %2B becomes a literal plus. Other components or receiving systems can use different rules, so compare with the target contract.
Further reading
Related articles
Keep exploring