PRACTICAL GUIDE

Inspect URL Parameters Without Losing Repeated Values

Separate a URL into its parts, understand plus signs and repeated query keys, and check a report before sharing it.

  • ◷ 3 minute read
  • Practical examples

Use an address with a predictable result

Paste https://example.com/search?q=hello+world&tag=pdf&tag=image#results into URL Inspector. The host should be example.com, the path /search and the fragment results. The query table should contain three rows: q with hello world, tag with pdf and tag with image. This small example makes it easy to notice a dropped value.

LipiCode parses the text in your browser without fetching the destination. That helps inspect a query without opening the link, but does not establish whether the destination is safe, genuine or reachable. Use the report to understand structure, not to approve a suspicious address.

Keep repeated keys visible

A query can contain the same key more than once. Turning it directly into an ordinary object can discard earlier values. LipiCode lists the parameters as ordered rows and retains both tag entries in the example. When debugging a filter or an API request, compare the receiving system’s treatment of repeated keys with the complete list.

An empty parameter is also useful evidence. A flag with no explicit value and a key followed by an equals sign can both appear with an empty decoded value. Keep the original URL if the exact spelling matters; the parsed report is an interpretation of the address, not a byte-for-byte archive.

Distinguish a plus sign from a space

Query parsing follows URLSearchParams: a plus sign in the query decodes to a space. To represent a literal plus, use %2B. Try q=a+b and q=a%2Bb separately; the first produces a b and the second a+b. Encoding an entire URL as if it were one query value changes its separators, so encode individual values when constructing a request.

Path and fragment fields in LipiCode keep their percent escapes. Query names and values are decoded. This difference is deliberate; do not assume every field in the report has undergone the same transformation. Browser parsing can also normalize the hostname and remove a default port.

Check for secrets before copying a report

The inspector flags embedded account credentials and omits the username and password from its report. Query strings can still contain access tokens, email addresses or private search terms. Read the parameters before copying, downloading or attaching a report to a bug ticket.

For a useful issue report, replace private values with a small synthetic example while keeping the repeated keys, escapes or empty values that trigger the problem. Include the expected interpretation and the actual result. A reproducible non-sensitive address is more useful than an unexplained screenshot of a long private link.

  • Check the hostname and path
  • Keep repeated parameters
  • Inspect decoded values
  • Remove private tokens before sharing

References and further reading

These primary or authoritative references support standards-dependent details. The examples explain how these details apply to the workflow on this site.