Query string parser

Paste a query string — or a whole URL, and the query is taken out of it — and get one row per parameter with the value decoded. Repeated keys stay repeated, plus signs become spaces, and a nested URL inside a parameter comes back readable rather than as a wall of percent sequences.

Off by default — the point of the page is to read them.

Result

The answer appears here as you type.

  • Where it runs

    Nothing is uploaded, because there is no file — it is worked out in this page.

  • No queue, no account

    It answers as fast as your machine can, and it never asks who you are.

  • As often as you like

    Nothing is counted and nothing is capped — answering again costs us nothing.

How it works

  1. Paste the query string or the whole URL into the box.
  2. Read the parameters. Each value is decoded as UTF-8.
  3. Tick the box if you need to see a value in its encoded form instead.

A repeated key is two values, not one

Nothing in the specification says a parameter name may appear only once, and plenty of systems rely on it: `?tag=a&tag=b` is how a multi-select arrives, and how most form libraries serialise a list of checkboxes. The correct reading is a list of pairs.

The obvious implementation reads it into an object, and an object cannot hold the same key twice — so one of the two values is silently dropped, and which one depends on whether the code keeps the first or the last. That is a bug people find much later, when a filter mysteriously applies to one tag out of two. This page lists both.

The plus sign, and the reason it means a space here

A query string is usually `application/x-www-form-urlencoded`, which is the format an HTML form posts in — and in that format a space is written as `+`. Plain percent-encoding has no such rule, so in a path a `+` is simply a plus character.

This page uses the form-encoded reading, because that is what a query string almost always is. The consequence to watch for is a value that contains a genuine plus — a phone number, a search for `C++`, a Base64 segment. Those have to arrive as `%2B` or they will be read as spaces, and if you are generating them that is on the encoding side rather than here.

A URL inside a parameter is the common hard case

Redirect targets, callbacks, `next` and `return_to` parameters all carry a whole URL as a value. It has to be encoded, so its own `?`, `&` and `=` become percent sequences, and the result is unreadable at a glance and easy to truncate by eye.

Decoding one row gives it back intact, including its own query string. If that inner URL has parameters you also need to read, paste it back in — this page will take the query out of a whole URL, so a two-level redirect chain takes two passes rather than any special handling.

Reading a tracking link

The five UTM parameters — source, medium, campaign, term and content — are a convention rather than a standard, which is why they are so often inconsistent: capitalisation varies, campaign names arrive with spaces encoded three different ways, and one link in a set has a typo the rest do not.

Seeing them as a list is what makes that visible. Two links that look identical in an email frequently differ in one parameter, and a campaign that reports oddly in analytics has usually been tagged inconsistently rather than tracked incorrectly.

Where query strings are the wrong place for something

A query string is logged. It is in the access log of every server and proxy the request passed through, in the browser history, in the referrer header sent to the next site, and often in an analytics payload. Nothing about it is transient.

So a token, a password reset code, a session identifier or an email address in a query string has been recorded in several places nobody intended. It happens constantly — password reset links are the classic case — and looking at a parsed query string is frequently how somebody first notices.

Query string parser: common questions

Why does my parameter appear twice?

Because it is in the query twice, and that is legal and meaningful — it is how a multi-select or a list of checkboxes is usually serialised. Tools that read a query string into an object drop one of the two, which is a bug that surfaces much later as a filter that only half applies.

A plus in my value became a space. Is that right?

Yes, for a query string. Query strings are normally form-encoded, where a space is written as +. A genuine plus has to be sent as %2B. If you are seeing this on a value that should contain a plus — a phone number, a Base64 segment — the encoding upstream is the problem.

Can I paste a whole URL rather than just the query?

Yes. Everything after the first question mark is taken as the query. If there is no question mark at all, the input is treated as a bare query string — and if it has no equals sign in it either, it is reported as having no parameters rather than parsed into one strange-looking row.

How do I read a redirect URL inside a parameter?

Decode it here, then paste the result back in. The inner URL comes back with its own query string intact, and this page will take the query out of a whole URL, so a two-level chain is two passes and needs nothing special.

Is the query string I paste sent anywhere?

No, and this is one of the tools where that matters most. Query strings pulled out of logs routinely carry session identifiers, reset tokens and email addresses — the very things that should not have been in a query string in the first place, and certainly should not be handed to a third party to be read.

Other tools