Components

Origin
https://api.example.com:8443
Protocol
https:
Hostname
api.example.com
Port
8443
Pathname
/v2/users
Search
?id=42&format=json&tag=caf%C3%A9
Hash
#section

Query parameters (3)

KeyRawDecoded
id4242
formatjsonjson
tagcaf%C3%A9café
Privacy: Parsing runs entirely in your browser via the native URL constructor. Zero HTTP requests during parsing — verify in DevTools' Network tab.

About URL Parser / Inspector

A URL parser decomposes any URL string into its structural components — protocol, hostname, port, pathname, query string, and hash fragment — using the browser's native URL API (which implements the WHATWG URL Living Standard). Distinct from URL encoding: parsing reveals structure; encoding transforms characters for transport safety.

Why use a URL Parser / Inspector?

Debugging URL-driven bugs (which parameter is wrong? what's actually in the path?), understanding deep links from analytics/tracking systems, auditing redirect chains, working with OAuth callback URLs where query parameters carry the auth state. The query-parameter table view makes it easy to spot duplicate keys, URL-encoded values that need decoding, and missing required params.

Who is it for?

Web developers debugging URL routing and query string handling, marketers auditing UTM parameter consistency across campaigns, integrators verifying OAuth/SSO callback URL structure, QA engineers inspecting deep links and analytics tracking pixels, and security researchers analyzing URL-based attack vectors.

How to use the tool

1

Paste any URL (full or partial — the tool tries to parse partial URLs against a base)

2

View the decomposed components: protocol, hostname, port, pathname, search, hash, origin

3

Inspect query parameters in a key/value table (with URL-decoded values shown)

4

For URL-encoded values, see both the raw form and the decoded form side-by-side

5

Copy any individual component for use elsewhere

Frequently Asked Questions

How do I parse a URL into its components?

Paste any URL (e.g., `https://api.example.com:8443/v2/users?id=42&format=json#section`). The tool uses the browser's native `URL` constructor to decompose it: protocol (`https:`), hostname (`api.example.com`), port (`8443`), pathname (`/v2/users`), search (`?id=42&format=json`), hash (`#section`), origin (`https://api.example.com:8443`). Query parameters are also displayed in a key/value table with URL-decoded values. Runs entirely in your browser — your URL never leaves the device.

What are the parts of a URL?

Per the WHATWG URL spec: **scheme/protocol** (`https:`), **authority** (user:password@host:port — userinfo is rare), **path** (`/users/42`), **query** (`?key=value&...`), **fragment/hash** (`#section`). Special components: **origin** = scheme + host + port (the security boundary for Same-Origin Policy). The path is hierarchical (segments separated by `/`); the query is unordered key=value pairs; the hash is client-side-only (never sent to the server by the browser, useful for SPA routing).

Is my URL sent to a server?

No — parsing runs entirely in your browser via the native `URL` constructor (a Web Platform API). Zero HTTP requests during parsing (verifiable in DevTools' Network tab). Safe for sensitive URLs (private OAuth callback URLs with tokens, internal API endpoints, debugging URLs containing auth credentials). Caveat: don't paste real secrets into ANY web tool's clipboard — even client-side tools leave traces (clipboard history, browser autofill).

What's the difference between this and URL Encoder/Decoder?

Different operations. [URL Encoder/Decoder](/tools/url-encoder-decoder/) **transforms** the URL string — percent-encoding special characters for transport (`space → %20`), and the reverse. URL Parser (this tool) **decomposes** the URL into components — protocol, host, path, query parts — without transforming it. Use URL Encoder/Decoder when you're constructing or sanitizing a URL string; use URL Parser when you're inspecting/debugging an existing URL's structure.

How does this handle query parameters?

Query parameters are extracted from the `?key=value&key2=value2` portion. Each key/value pair is parsed and displayed in a table. Values are URL-decoded automatically (so `%20` shows as space, `%C3%A9` shows as `é`). **Duplicate keys**: the URL spec allows duplicates (`?id=1&id=2`); the table shows both. The browser's `URLSearchParams` iterator preserves order. For programmatic access: `new URL(str).searchParams` gives you the URLSearchParams object directly.

What's the URL origin and why does it matter?

**Origin** = scheme + host + port. Example: `https://app.example.com:443` (port omitted for defaults — 443 for HTTPS, 80 for HTTP). The origin is the security boundary for the **Same-Origin Policy** — cookies, localStorage, and JavaScript access are scoped to the origin. Two URLs with the same scheme + host + port share an origin (and trust each other); different = cross-origin (subject to CORS for cross-origin fetches — see [CORS Header Checker](/tools/cors-header-checker/)). For OAuth, the registered callback URL must match the origin of the redirect destination.

Can I parse relative or partial URLs?

Yes, but they need a base. The `URL` constructor accepts: `new URL('/path', 'https://example.com')` → resolves `/path` against the base. The tool can use a default base (like `https://example.com`) for parsing relative URLs, or you can supply your own. For purely standalone parsing: paste a full absolute URL (with scheme). For inspecting a redirect target relative to a current page, supply both. The WHATWG URL spec handles all the edge cases (relative `..`, scheme-relative `//`, protocol-relative).

Why doesn't the URL spec preserve hash fragments server-side?

The hash (`#section`) is by convention **client-side only** — browsers do NOT send it in the HTTP request. The server sees only protocol + host + path + query. This makes hash fragments useful for client-side state (SPA route, deep link to a heading) without server round-trips. **Common confusion**: analytics/tracking pixels can't see the hash unless JavaScript explicitly captures and sends it; OAuth state in the hash (Implicit Grant flow — now deprecated) was a security choice to keep tokens off the server log. For modern OAuth, use the Authorization Code flow with PKCE — state in query, not hash.

Share This Tool

Found this tool helpful? Share it with others who might benefit from it!

💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.

Support This Project

Buy Me a Coffee