Query String Parser

Most query string tools stop at showing you the parameters. You paste a link, you get a tidy table, and the moment you actually want to change something you are back to hand editing the raw string and re-escaping spaces yourself. This one both reads and writes, so a pasted URL drops every parameter into an editable list. Rename a key, fix a value, delete the tracking junk, move a param up, add a new one, and the tool rebuilds the correctly percent-encoded query string and the full URL for you, live and ready to copy. Nothing is uploaded, it all runs in your browser, so a link carrying a session token or an API key never leaves your machine.

The decoding still happens up front, so you read the real values, not the wire format. ?name=John%20Doe&age=30 shows up as name = John Doe and age = 30, sitting in two fields you can edit right away.

1. Paste your input. A full URL (https://shop.example.com/search?q=running+shoes&size=10), a query string with a leading ?, or just the bare key=value&key=value part. The parser works out which one you handed it.
2. Read the decoded parameters. Each parameter is a row with its value already decoded. %20 reads back as a space, %C3%A9 as é, and a + becomes a space too, so what you see is what the server actually receives.
3. Edit anything inline. Click a key or a value and change it. Blank out a value, rename a key, correct a typo in a UTM tag. The rebuilt output updates as you type.
4. Add, remove, reorder. Use Add parameter to build a new pair from nothing, the ✕ to drop one, and the arrows to move a param up or down when order matters.
5. Copy the result. The Rebuilt query string and Rebuilt full URL boxes stay correctly encoded no matter what you type. One click copies either one.
6. Want JSON instead? Switch to the JSON view for a formatted object, where a repeated key comes back as an array. Load the sample if you just want to poke at it, or Clear to start over.

Hand editing a query string is where the mistakes hide. Change a value that has a space in it and you are supposed to know it becomes %20, not a literal space. Put an ampersand inside a value, say a store name like "Ben & Jerry", and if you forget to write it as %26 the raw & splits your one parameter into two broken ones. Miss an = inside a value and the whole pair reads wrong. People get this subtly wrong constantly, and the URL looks fine until some downstream system reads it and the data is mangled.

So the tool does the escaping. You type the human-readable value into the field, "Summer Sale", redirect_uri=https://app.example.com/cb, whatever, and the rebuilt output encodes it the correct way. A space rebuilds as %20, an ampersand as %26, a slash inside a value gets escaped so it is read as data and not structure. You never have to remember the hex, and you never ship a link that quietly breaks on the far end.

That is the real reason to reach for this over a read-only parser. Strip a fbclid or a gclid off a link before you share it. Bump page=2 to page=5. Swap a utm_source from newsletter to twitter across a batch of links. Add a debug=true to reproduce a bug. All of it without opening a code editor or firing up a REPL, and with the encoding handled for you.

A query string can carry the same key more than once, and that is valid. ?tag=news&tag=sport&tag=tech is how you pass a list through a URL. A lot of tools quietly ruin this, they keep only the last value and throw the rest away, which is exactly what a naive Object.fromEntries does. Ours keeps every value as its own editable row, so you can change one, remove one, or add a fourth without touching the others. Flip to JSON and it comes back as a proper array, "tag": ["news", "sport", "tech"]. Nothing is lost to a silent last-wins overwrite, and if some system upstream is dropping your repeated values, you will see it here.

Empty and missing values get treated honestly too. flag= is a key with a blank value. A bare flag with no equals sign is present but valueless, and when you rebuild, a bare flag stays a bare flag rather than getting a stray = bolted on. That fidelity matters when a feature flag switches on by mere presence.

A few classics that bite people over and over.

Double-encoding is the common one. A space becomes %20, then something encodes that again and the % itself turns into %25, so you end up staring at %2520. If you paste a mangled link in and see %2520 in a value, you know some step encoded twice. Decode it here, fix the value, copy the clean version back out.

The + versus %20 mix-up. In a query string a + means space, but in the path part of a URL a + is a literal plus. Tools that treat the whole URL the same way mangle filenames that contain a plus. This one decodes + to a space only inside the query, which is where the rule actually applies.

And if the input is broken, a lone % with no hex behind it like x=50%, the parser does not fall over. It leaves that piece as-is and keeps reading the rest, so one bad character never kills the whole result. That row also gets flagged and rebuilds exactly as you pasted it, because re-encoding a value nobody could decode hands you back a different request than the one you were looking at. That is a small thing until you are staring at a malformed link some third-party system handed you.

Two honest limits worth knowing. This is a flat parser and builder, it works in key=value pairs, including repeated keys as arrays. It does not try to reconstruct deeply nested objects out of bracket notation like filter[price][min]=10, because that is a framework-specific convention, not part of the URL standard, and guessing at it gives wrong answers as often as right ones. And when you rebuild, spaces come out as %20 rather than +. Both encodings mean a space to any correct decoder, %20 is just the safer, more universal one.