Query String to JSON

A URL has no types: page=2 is two text characters, not an integer. The parser hands back exactly what was there, so you see "2" instead of 2 and "false" instead of a boolean. If the object goes on into code, cast the fields you care about yourself — automatic type guessing breaks phone numbers and product codes that begin with a zero.

A plain JSON object cannot hold the same key twice, so only the last occurrence survives. The URL spec allows repeats and many backends collect them into an array, but a flat object has no way to express that. When a link carries repeated parameters, rebuild them into an array by hand after parsing, or you will lose data silently.

Pasting only the tail after the ? is the predictable route, as the placeholder suggests. A full address with scheme and path parses less cleanly: the segment before the question mark can end up as a stray key. Trimming the string once at the question mark leaves you with exactly the parameters and nothing else.

Percent triplets are decoded back into ordinary characters, so campaign names and search terms are legible immediately. A + sign is different: in classic form encoding it stood for a space, but percent decoding leaves it as a literal plus. If the link came out of an HTML form submission, replace the plus signs with spaces yourself.

It comes back as one long string full of braces and quotes, which is accurate — to the URL it was only text. Copy that value out and run it through the JSON Formatter and Validator to see the structure. The page decodes a single layer of percent escapes; it does not recursively unwrap formats nested inside a value.

The parsing runs in the page and nothing is transmitted, so the field content stays in your browser. The link itself is the risk: a token in a query string is already sitting in browser history, server logs and probably the chat you copied it from. Parse it if you are investigating an incident, then revoke that token in the service.