URL Parser and Query Inspector

Why parse offline?

Most URL parsing and inspection tools are server-backed. When you paste a URL into them, the full URL, including any auth tokens, session IDs, API keys, or CSRF tokens embedded as query parameters, is transmitted to a third-party server. For URLs that contain credentials or identifiers tied to live accounts, this is a meaningful security risk. Even services that claim to process URLs in memory still receive the raw string over the network, which exposes it to logging, caching, or accidental retention on the server side. Once a URL has left your machine, you have no control over where a copy of it ends up, and query parameters are especially easy to overlook because they sit at the end of an address that looks harmless at a glance. Parsing locally removes that exposure entirely, which is why this tool never transmits anything you type.

This tool uses the browser's built-in URL constructor,¹ so parsing happens entirely in your tab with zero network requests. You can verify this yourself by opening DevTools, switching to the Network tab, and watching for outbound requests as you type. There are none. Every keystroke stays on your machine, which means sensitive query values such as auth tokens and session IDs never leave your browser.

URL components explained

Every URL can be broken into a handful of named parts, and the browser's URL object exposes each one as a readable property.¹ Take the example https://api.example.com:8080/v1/users?role=admin#top. Feeding that string into the constructor returns an object whose fields map directly onto the protocol, host, path, query, and fragment you see in the address bar.

Host, port, and origin

protocol: https:, the scheme including the trailing colon. hostname: api.example.com, just the domain with no port. port is 8080; for default ports (80 for HTTP, 443 for HTTPS) this field is empty, which is why the tool displays a dash instead of a blank cell for default-port URLs.² host combines hostname and port: api.example.com:8080, and origin goes a step further by pairing that host with the scheme to form https://api.example.com:8080, the value browsers use for same-origin checks.²

Path, query, and fragment

pathname: /v1/users, the path after the host not including the query string. search: ?role=admin, the raw query string with the leading question mark included. hash: #top, the fragment identifier that points to an anchor within the resource. href is the normalised full URL as the browser resolved it, and it reflects any normalisation the constructor applied, such as adding a trailing slash to a bare host.

Working with query parameters

Query parameters carry the data that many web apps rely on for filtering, tracking, and API calls. They live after the ? and are formatted as key=value pairs separated by &, and the URLSearchParams API parses them into individual entries while handling percent-decoding automatically so that %20 becomes a space and %2F becomes a forward slash.³

Duplicate keys and recompilation

The same key can appear multiple times in a query string; for example ?tag=js&tag=astro. Both entries appear as separate rows in the Parameters grid, so you can see every value a request is sending. If you edit a value and recompile, duplicate keys are collapsed to one per key, because URLSearchParams.set() replaces all values for a given key.⁴ This behaviour is intentional and matches the URL standard, and the tool notes it in the spec and explains it in the FAQ.

If you need to preserve every duplicate value rather than collapsing them, use the URLSearchParams.append() method directly in your own code instead of .set(). The inspector prioritises a predictable recompiled output, but the underlying API gives you full control when you are building query strings yourself, so you can choose the behaviour that matches your use case.

Encoded and long values

Many real-world URLs carry values that are both heavily encoded and surprisingly long. JWTs, OAuth tokens, and large base64-encoded blobs are all valid query parameter values, and they can run to several thousand characters. The browser's URL constructor decodes them automatically, so the raw string appears readable in the Parameters grid without any extra decoding step on your part.³

How the layout handles overflow

Long values do not break the table or grid layout. Each value cell has a max-height with overflow-y: auto, so the cell scrolls vertically rather than stretching the page. The table-layout: fixed rule on the properties table prevents horizontal overflow regardless of value length, which keeps every row aligned even when a single parameter value is wider than the viewport.

When to inspect encoded values

Inspecting an encoded value is useful when you suspect a token has been truncated by a proxy, when a third-party service sends more data than you expected, or when you need to confirm that a signature blob arrived intact. Because the grid shows the decoded string directly, you can scan for unexpected prefixes, extra padding, or altered characters without copying the value into a separate decoder.

Security edge cases when parsing URLs

URLs are a common attack surface in web applications. Open redirect vulnerabilities occur when a server uses a URL from user input or a query parameter as a redirect destination without validating the target's host. Parsing the destination URL and confirming its hostname matches your expected domain is the correct fix, and the inspector makes it straightforward to check a suspicious destination URL for unexpected hosts, unusual ports, or encoded path segments that could disguise a malicious target.⁵ Server-side request forgery (SSRF) is a related vulnerability where a server fetches a URL supplied by an attacker, reaching internal services that should not be publicly accessible; inspecting the host and port components of user-supplied URLs is the first validation step.⁶

Parameter pollution occurs when an attacker supplies the same query key multiple times with different values, exploiting inconsistencies in how different server-side frameworks handle duplicate keys.⁷ The inspector shows all key-value pairs including duplicates, so you can see exactly what a request's query string contains before deciding how to process it. Percent-encoding confusion is another edge case: a path segment containing %2F (an encoded forward slash) is distinct from a literal slash in URL parsing, but some servers normalise it before routing, creating path traversal opportunities.⁸ Because CapyToolkit uses the browser's native URL constructor, the parsing behaviour matches what browsers themselves do, giving you the most accurate view of how a URL will be interpreted in a browser context.