URL Parser / Query String Splitter

About this tool

This URL parser breaks any absolute URL into its structural components - protocol, host, pathname, search string, hash fragment - and separately decodes all query parameters into individual key-value pairs. URLs used in OAuth flows, API callbacks, redirect chains, and analytics tracking often contain multiple encoded parameters that are difficult to read as a raw string. This tool makes them instantly legible without writing any code.

Real example

Input: https://example.com/callbackcode=abc123&state=signed-in&redirect_uri=https%3A%2F%2Fapp.example.com%2Fdashboard#done

Parsed URL components:
protocol: https:
host: example.com
pathname: /callback
search: code=abc123&state=signed-in&redirect_uri=https%3A%2F%2F...
hash: #done

Decoded query parameters:
code = abc123
state = signed-in
redirect_uri = https://app.example.com/dashboard (decoded from percent-encoded form)

The redirect_uri parameter is URL-encoded in the raw string - the parser decodes it so you can see the actual value immediately.

Common use cases

• OAuth callback debugging: Authorization code flows return callbacks like /callbackcode=...&state=...&error=.... Paste the full callback URL here to instantly verify the authorization code, state parameter, and any error codes.
• API link inspection: Signed API URLs (AWS S3 presigned URLs, Stripe webhook URLs) embed credentials and expiry times in query parameters. Decode them here to verify the correct values without accidentally leaking them into logs.
• UTM parameter QA: Marketing campaigns embed UTM parameters in URLs (utm_source, utm_medium, utm_campaign). Paste campaign links here to verify every parameter is correctly set before launch.
• Redirect chain analysis: Long redirect URLs often have the destination URL encoded as a query parameter. Parsing reveals the actual destination without following the link.

How it works

The URL is passed to the browser's native new URL(input) constructor. This gives access to all components: href, protocol, host, pathname, search, and hash. Query parameters are iterated with url.searchParams.forEach(), which automatically URL-decodes percent-encoded values like %20 (space) and %2F (/). All processing is local - no network requests are made.

Common mistakes

• Relative URLs are not supported: The browser's URL API requires an absolute URL with a protocol. /callbackcode=abc will fail - you need https://example.com/callbackcode=abc. Add a placeholder domain if you are only interested in the query string.
• Double-encoded parameters: Sometimes redirect_uri is encoded twice (%2520 instead of %20). The parser decodes one layer. If values still look encoded after parsing, the source URL has double-encoding - a common bug in redirect implementations.
• Fragment (#) is not sent to the server: The hash/fragment portion of a URL is never sent in HTTP requests - it exists only in the browser. If you are debugging server-side behavior, the # portion is irrelevant. It is typically used for single-page app routing or OAuth implicit flow tokens.

FAQ

Are query parameters URL-decoded
Yes. URLSearchParams automatically decodes percent-encoded values, so hello%20world becomes hello world in the output.

What if a parameter appears multiple times
Some URLs include the same key multiple times (e.g., tag=a&tag=b). The parser outputs each occurrence as a separate line.

Can I parse data: or blob: URLs
No. This tool is designed for http/https URLs. Data URIs and blob URLs have different structures and are not supported.

Is anything sent to a server
No. Parsing uses the browser's built-in URL API - no network requests are made and the URL is not transmitted anywhere.

URL structure: what each component means

A URL (Uniform Resource Locator) is a structured string that identifies both the location of a resource and how to access it. Each component serves a distinct purpose, and understanding the boundaries between them matters when writing parsers, routing logic, or security rules.

Scheme: The protocol — https, http, ftp, ws, wss. The scheme determines how the browser connects and what security properties apply. Mixing schemes (e.g., loading HTTP resources from an HTTPS page) triggers mixed-content warnings and may be blocked by CSP.

Host: The domain name or IP address of the server. In security contexts, the host is the primary trust boundary. A CSP connect-src allowlist, a CORS policy, and a cookie Domain attribute all use the host as their reference point. Subdomains are distinct hosts — api.example.com and example.com are different origins unless explicitly included.

Port: Explicitly specified as :8080, or implicit (443 for HTTPS, 80 for HTTP). The port is part of the origin alongside the scheme and host. A server on https://example.com:8443 is a different origin than https://example.com — relevant for CORS and cookie scoping.

Path: The hierarchical resource location after the host. REST APIs use path segments to encode resource type and identity (/users/42/orders). Route matching in frameworks like Express or Next.js is path-based. Path traversal vulnerabilities (../../etc/passwd) happen when user-controlled input reaches path construction without normalization.

Query string: Key-value pairs after the ?, percent-encoded and joined by &. The browser's URLSearchParams API handles encoding and decoding. Watch for SQL injection and XSS in query parameters that reach server-side code or DOM without sanitization. Duplicate parameter names (same key, multiple values) are allowed by spec and handled inconsistently across frameworks.

Fragment: Everything after the #. The fragment is processed entirely by the browser and is never sent to the server in an HTTP request. This makes it suitable for client-side state (single-page app routing) and for passing sensitive data in shareable links without server-side logging — the technique used by Secure Paste to keep encrypted content off the server.

Debugging URL issues

Encoding problems: Spaces must be encoded as %20 (or + in form data). Non-ASCII characters must be percent-encoded. URLs that work in a browser but fail in a curl request often have encoding differences — the browser is more forgiving. Paste the URL here to see the decoded parameter values and identify what the server is actually receiving.

Redirect loops: When debugging redirect chains, parsing each URL in sequence reveals whether a path or query parameter is changing across redirects in a way that causes the loop. Look particularly at tracking parameters that modify the redirect target.

Webhook verification: Many webhook providers include a signature or timestamp in a query parameter. Parsing the incoming URL to extract those values is the first step in validating the webhook before processing the payload.

For related tools: Regex Tester for building URL path extraction patterns, Unix Timestamp Converter for decoding epoch values found in query parameters, and Base64 Encoder/Decoder for decoding base64-encoded query values.