Reading a URL Like a Pro: Query Strings, Encoding, and Where Bugs Hide

URLs are so familiar that we stop seeing their structure — until a link breaks because an ampersand landed in the wrong place, or a redirect drops half its parameters. A URL is a small, strict grammar, and understanding its parts (and how encoding works) turns "why is this parameter missing?" into a quick diagnosis. The URL Parser breaks any URL into its components, which is the fastest way to see what a browser or server actually receives.

The anatomy of a URL

Take https://api.example.com:443/v2/search?q=hello+world&page=2#results:

• Scheme — https. The protocol.
• Host — api.example.com. Optionally a port (:443).
• Path — /v2/search. The resource.
• Query string — q=hello+world&page=2. Key/value pairs after the ?, separated by &.
• Fragment — results. Everything after #; it never leaves the browser and is not sent to the server.

That last point trips people up regularly: the fragment is client-side only. If you are debugging why a server never sees a value, check whether it is sitting after a #.

Percent-encoding: the part that breaks things

The query string can only safely contain a limited set of characters. Anything else — spaces, &, =, /, ?, non-ASCII — must be percent-encoded: a space becomes %20 (or + in form-encoded queries), an ampersand becomes %26, and so on. Most URL bugs are encoding bugs:

• An unescaped & in a value splits one parameter into two. ?note=cats & dogs becomes note=cats plus a stray dogs key. The value should be note=cats%20%26%20dogs.
• Double-encoding. Encoding an already-encoded string turns %20 into %2520, and the server hands you a literal %20 instead of a space. This happens when two layers both "helpfully" encode.
• + vs %20. In the query component of a form submission, + means space; in the path, it is a literal plus. Mixing contexts leads to values that are off by exactly one space-or-plus.

The URL Parser decodes each parameter for you, so you can see the actual value your code receives rather than the escaped soup in the address bar. If a value is itself Base64 (common for tokens and state), the Base64 Encoder / Decoder reveals what is inside it.

Query strings are untrusted input

A practical security note: everything in a URL is attacker-controllable. Query parameters flow into search filters, redirects, and templates, which makes them a classic injection and open-redirect vector. Two habits:

• Validate and encode on output. Never drop a raw query value into HTML, SQL, or a shell without escaping for that context.
• Never put secrets in URLs. Query strings land in browser history, server logs, and Referer headers. Tokens and personal data belong in headers or the request body, not the address bar.

A quick debugging flow

When a link or request misbehaves:

1. Paste the full URL into the URL Parser and confirm each parameter decodes to the value you expect.
2. Check for a stray # hiding data client-side, or an unescaped & splitting a value.
3. Look for double-encoding (%25 where you meant %).

For the broader picture of how requests travel and where headers fit, the Web Security Headers Guide is a useful companion.

The takeaway

A URL is scheme, host, path, query, and fragment — and the query string, with its percent-encoding, is where most bugs and a fair amount of risk live. When something is missing or garbled, decode it with the URL Parser before assuming your code is wrong; more often than not, the value was mangled in transit.