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.

Paste a URL whose domain contains non-ASCII characters and the hostname row shows something that looks corrupted. It is not. A domain like münchen.de appears as xn--mnchen-3ya.de in the hostname row, because the URL Standard converts every domain to its ASCII-compatible encoding before anything else touches it, and that xn---prefixed punycode form is how resolvers and certificate checks actually address the site.³ For display, your browser's address bar usually renders the Unicode form back, but the row here reports the ASCII form because it is the one the whole lookup chain uses. Nothing about the conversion changes where the URL points.

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.

The RFC 3986 names for the same parts

The property names above come from the WHATWG URL Standard, but the questions people ask about URLs often arrive in the older vocabulary of RFC 3986, the IETF's generic URI syntax. RFC 3986 names five components: scheme, authority, path, query, and fragment, where the authority is the //host:port group as a whole, userinfo included when present.⁴ As the successor spec browsers actually implement, the WHATWG standard describes the same address bar string in its own vocabulary: what RFC 3986 calls the authority, the URL API splits into the hostname, port, and origin properties you read above.

Read the example above in both vocabularies and the mapping locks in. For https://api.example.com:8080/v1/users?role=admin#top, RFC 3986 labels https the scheme, api.example.com:8080 the authority, /v1/users the path, role=admin the query, and top the fragment. Case sensitivity falls out of the same spec: the scheme and host are case-insensitive and normalized to lowercase, while the other components are case-sensitive as written, so /Index.html and /index.html are different addresses and the hostname row here shows the lowercased form.⁴ The URL structure reference walks the full grammar if you need every delimiter and subcomponent named.

Relative references explain the most common paste error. A string like /v1/users or //api.example.com carries no scheme or host of its own, so RFC 3986 treats it as meaningful only against a base URL, resolved by a defined algorithm that borrows the base's missing pieces. Give the browser's URL constructor a base as its second argument and it resolves the reference against that base; give it a bare relative string alone and it throws, which is exactly the scheme error this tool reports.² If you are debugging a relative URL that will not resolve, the relative URL resolution guide works through the merging rules with examples.

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. The grid handles values thousands of characters long, so even a URL bloated far past comfortable reading length still breaks down completely here.

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.