URL Query Params Parser

Understanding Everything After ? in a Long URL

Long URLs often look harder than they really are. The query portion is usually a list of small name-value pairs. A shopping site may use them for filters, a search page for the search term, an analytics link for campaign tags, or an API for pagination and options.

Reading the pieces separately is often enough to explain a long link: which names repeat, which characters were encoded, which values are blank, and which fragment after # sits outside the query.

Functional Parameters and Tracking Parameters Serve Different Purposes

Some parameters change the page itself: page=2, sort=price, lang=en, or category=books. Removing one can change the content you see.

Others are commonly used for attribution or analytics, such as utm_source, utm_medium, and utm_campaign. Those often do not control the main content, but there is no universal rule that says an unfamiliar parameter is safe to delete. A site can use any parameter name for experiments, signed state, referrals, access control, or application logic.

Repeated Parameters Are Real Data

A query is an ordered sequence of pairs, not necessarily a one-key-one-value object. ?tag=books&tag=music can intentionally represent two selected tags. Different frameworks expose repeated values differently: some return arrays, some return the first value, some the last, and some require a dedicated “get all” method.

Keeping every occurrence in order avoids silently collapsing a repeated parameter. A grouped array view can then sit beside the ordered source without choosing a first-value or last-value policy on behalf of the receiving application.

+, %20, and %2B Are Easy to Confuse

Browser query APIs commonly use application/x-www-form-urlencoded rules. In that form, + represents a space. A real plus sign is normally serialized as %2B, while a space can also appear as %20. This is the same tuple parsing model defined for URLSearchParams by the WHATWG URL Standard.

The decoded results may look similar even though their raw source differed. Preserving both views is useful when a client and server disagree about encoding. Browser serialization can also change spelling: mutating URLSearchParams may turn a space into + or re-encode characters even when the decoded value stays the same.

Raw Values Matter for Signatures and Double Encoding

If you only want to read a link, decoded text is usually enough. Developers sometimes need the raw representation instead. Signed URLs, OAuth callbacks, webhook validation, cache keys, analytics pipelines, and APIs can depend on exactly how a value was serialized.

For example, %2520 can indicate double encoding: one decoding step produces %20, and a second produces a space. Seeing the raw source next to the decoded result helps identify which layer added the extra encoding.

flag and flag= Are Not Textually Identical

Common browser query APIs expose both ?flag and ?flag= as an empty decoded value, but the original spelling is different. ?=value has an empty name. Backend frameworks can normalize these edge cases differently, so the output keeps track of whether the equals sign was actually present.

The Fragment After # Is Kept Separate

In a full URL, the fragment begins at #. Browsers commonly use it for in-page navigation or client-side state, and it is not sent as part of the HTTP request target. In raw-query mode there is no surrounding URL context to prove that # starts a fragment, so it stays in the query data and the ambiguity is reported.

Malformed Percent Encoding Can Still Produce a Browser Value

Browser URL parsing is intentionally tolerant. An incomplete percent escape may remain as literal text, while invalid UTF-8 byte sequences can decode with replacement characters. That helps browsers handle imperfect URLs, but it can hide data-quality problems in APIs and signature workflows.

Browser-style decoding can still produce text from imperfect input, so the raw component stays beside the decoded value and warnings remain visible. A decoded result therefore means a browser-compatible parser produced something, not that the source encoding was clean or canonical. The exact parsing and serialization model comes from the WHATWG URL Standard.

Ambiguous Text Needs an Explicit Input Type

Auto mode tries to distinguish a URL from a bare query string. Most inputs are obvious, but some custom schemes, relative paths, or unusual raw queries can be ambiguous. If you know what the source is, selecting Full or relative URL or Raw query string removes that guess.

Parsing Cannot Tell You Which Parameters Are Safe to Remove

Parameter names, values, order, duplicates, fragments, raw encoding, and decoding warnings can be read from the URL itself. The URL alone cannot prove that a parameter is safe to remove, that a tracking-looking parameter has no server-side effect, that a signed URL is still valid, or which repeated value a particular backend framework will choose. Those answers belong to the receiving application.

Follow the URL Into the Next Debugging Step