Duplicate parameter pollution
A proxy might use the first value while an application uses the last. Preserve every occurrence and align duplicate handling across security and business layers.
Inspect the parameter sequence
Parse URL query strings online
Paste a hierarchical absolute URL containing ://, a value beginning with ?, or a raw query. Requiring the authority marker keeps scheme-shaped raw fields such as foo:bar=baz in raw-query mode. Inspect up to 10,000 non-empty fields within a 200,000 UTF-16-code-unit limit.
Loading the query string parser…
Enable JavaScript to inspect ordered parameters. The form-encoding and duplicate-key guide remains readable below.
A list, not a plain object
How URLSearchParams parses a query string
A query string commonly contains name/value entries separated by ampersands. Within an entry, the first equals sign separates the encoded name from its encoded value. The same name can appear more than once, an entry can have an empty value, and the order can be meaningful to a particular application even though many servers treat it as insignificant.
LiveParse uses browser URLSearchParams semantics, which are based on the WHATWG application/x-www-form-urlencoded parser. Before percent-decoding, each literal plus sign is interpreted as a space. A plus that belongs to the data therefore needs the encoded form %2B. Percent-encoded UTF-8 sequences become Unicode text.
The result is an ordered list of pairs rather than a single-value JavaScript object. That distinction prevents repeated names from being overwritten. For tag=red&tag=blue, both entries remain available in their original parsed order. For empty=&flag, both names remain present with empty decoded values.
The lossless pair view records each accepted field's original encoded name and value and whether = appeared. The grouped map keeps every decoded value in an array. The rebuilt query is intentionally canonical: equivalent spellings can change, a bare key becomes a key followed by equals, and spaces serialize as plus. Empty separator-only segments are reported but omitted. Keep the complete original input when signatures or forensic evidence depend on characters outside accepted fields.
- Accepted input
- A hierarchical
scheme://URL, a leading-?value, or raw query text. - Data model
- An ordered list of decoded pairs with original field spelling metadata.
- Duplicate names
- Retained separately and grouped into arrays only in the map view.
- Empty values
- Retained, with
=presence recorded in lossless pairs. - Limits
- 200,000 UTF-16 code units and 10,000 non-empty fields.
Read every occurrence before grouping
Query parameter parsing example
Encoded entryDecoded nameDecoded value
utm_source=newsletterutm_sourcenewslettertag=redtagredtag=bluetagblueq=caf%C3%A9+teaqcafé teaempty=emptyempty stringKeep context and sequence
How to inspect URL query parameters
- 1
Paste one supported input shape
Use a hierarchical
scheme://URL, query text beginning with?, or a raw query string. For opaque schemes, host, path, or relative resolution, use the full URL parser. - 2
Review ordered entries
Look for repeated names, empty names or values, plus signs, encoded delimiters, and parameters whose position differs from the expected request.
- 3
Apply destination rules separately
Confirm whether the receiving framework keeps the first value, last value, every value, or rejects duplicates. URLSearchParams parsing cannot determine that business rule.
Decoded pairs do not settle application semantics
Repeated keys, blank values, and serialization pitfalls
Absent versus empty
A missing key, a bare key, and key= are not always the same to application logic, even though URLSearchParams gives the latter two an empty string value.
Literal plus loss
Parsing raw C++ under form rules yields spaces. A producer must serialize that value as C%2B%2B when plus signs are data.
Signature mismatch
Reordering entries or normalizing their serialization can change an HMAC or signed URL. Follow the protocol's exact canonicalization algorithm rather than a generic sort.
Choose the tool by the layer you need
Query parser vs URL parser vs URL decoder
Use this page when the job is to inspect a form-style parameter sequence. Use the URL Parser when an absolute or relative URL must be interpreted as scheme, host, path, query, and fragment. Use the strict URL Decoder when malformed percent triplets or invalid UTF-8 must be reported rather than recovered.
URLSearchParams is designed for interoperable browser form behavior rather than forensic validation. LiveParse therefore performs a strict validation pass first: malformed triplets, invalid percent-encoded UTF-8, and unpaired UTF-16 surrogates stop the operation. It then uses URLSearchParams for form decoding, while the pair output keeps the original encoded field spellings.
No mode on this page checks that UTM values are accepted by an analytics platform, that a signed URL is authentic, that an OAuth state parameter matches a session, or that a redirect target is allowed. Those are destination-specific validations.
Need to create a safe value?
Encode each query name and value with form rules instead of concatenating raw ampersands, equals signs, spaces, or plus signs.
Open the URL encoder →Parameters frequently contain private data
Parse copied query strings without a network request
Query strings from callback links, server logs, support tickets, and analytics exports may include email addresses, search terms, invite codes, signed expirations, object identifiers, session values, or OAuth authorization data. Parsing takes place in this browser tab and does not send the input to an API or visit a pasted address.
Local processing cannot retract data already recorded in browser history, proxy logs, analytics systems, screenshots, or clipboard managers. Redact secrets before copying parsed output into a public issue, chat, documentation example, or prompt. A parameter being readable does not mean it is safe to disclose.
The 200,000-code-unit bound is for responsive inspection, not for constructing requests of that size. Actual request-target limits vary widely, and long query data may be rejected or truncated before it reaches an application. Use request bodies and an appropriate protocol when a large structured payload must be transmitted.
- Runs locally
- Parsing and display occur in the current browser tab.
- Does not run
- No navigation, DNS lookup, HTTP fetch, redirect following, or analytics validation.
- Still sensitive
- Clipboard, screenshots, extensions, logs, and shared output remain outside the parser boundary.
Questions answered
Query string parser FAQ
What does a query string parser do?
A query string parser splits form-style query text into an ordered sequence of decoded name and value entries. It handles ampersand separators, percent-encoded bytes, plus-as-space behavior, repeated names, and empty values according to browser URLSearchParams semantics.
Does URLSearchParams preserve parameter order?
Yes. Iteration follows the parsed list order, so this tool displays entries in that order rather than sorting them. A receiving application may still sort, group, or ignore parameters, so order should not be treated as a universal business rule.
How are repeated query parameter names handled?
Each occurrence remains a separate ordered entry. For tag=red&tag=blue, the parsed sequence contains two tag entries. Do not collapse them to one value unless the destination application's documented rules require that transformation.
What happens to empty query values?
An entry such as empty= has an empty decoded value and remains present. A bare name such as flag also has an empty decoded value, but LiveParse lossless pair JSON records whether the equals sign appeared and retains each accepted field's original encoded spelling.
Why does a plus sign become a space in query parameters?
URLSearchParams uses application/x-www-form-urlencoded rules, where a literal + in the encoded input represents a space. A data value that actually contains plus must encode it as %2B. General URL components outside form-style query parsing do not always use this rule.
Does this query parser reject malformed percent-encoding?
Yes. Although URLSearchParams alone has recovery behavior, LiveParse first validates every non-empty field and rejects malformed percent triplets, invalid percent-encoded UTF-8, and unpaired UTF-16 surrogates. It then uses URLSearchParams for form-style decoded values.
Does this query parser upload or request the input?
No. Query parsing runs in the current browser tab. The tool does not upload the text, navigate to a pasted address, resolve a hostname, fetch remote content, follow redirects, or validate an analytics destination.
What are the query string parser limits?
The parser accepts at most 200,000 UTF-16 code units and 10,000 non-empty fields in one operation. Empty segments between separators are counted and reported but not returned as pairs. Real browsers, proxies, servers, and applications can impose much smaller request-target limits.