DevToolKit

URL Parser & Analyzer

Decompose any URL into protocol, hostname, port, path, query parameters, hash, and auth credentials using the native URL API.

Try:
Native URL API

Enter any URL to instantly break it down into its components: protocol, hostname, port, path, query parameters, hash, and authentication credentials. Uses the browser's built-in URL parser for accurate results matching WHATWG URL Standard behavior.
Was this tool helpful?

How to Use

Break down any URL into its individual components directly in your browser. All parsing uses the native URL API — no data is sent to any server.

  1. Enter a URL in the input field. You can paste a full URL with protocol, or just a domain — the tool automatically prepends https:// if no scheme is provided.
  2. View the breakdown showing protocol, hostname, port, path, query string, hash fragment, and any authentication credentials. Each component appears in its own row.
  3. Inspect query parameters in the dedicated table below the component grid. Each key-value pair is displayed separately with its own copy button.
  4. Copy any component by clicking the clipboard icon next to each row. Use this to extract specific parts like the hostname for CORS configuration or query parameters for debugging.
  5. Try quick examples by clicking the preset buttons (Basic, FTP + Auth, Complex, IPv6) to see how different URL types are parsed.

About This Tool

Anatomy of a URL

A Uniform Resource Locator (URL) is a structured reference to a web resource defined by RFC 3986. Every URL follows the general syntax: scheme://[userinfo@]host[:port]/path[?query][#fragment]. Understanding these components is essential for web development, API debugging, security auditing, and network troubleshooting. The scheme (protocol) identifies the access mechanism — https for encrypted HTTP, ftp for file transfer, ssh for secure shell. The host identifies the server, either as a domain name or IP address. The port number is optional and defaults to the well-known port for the scheme (80 for HTTP, 443 for HTTPS). The path navigates to a specific resource on the server. The query string carries key-value parameters, and the fragment references a specific section within the resource.

RFC 3986 and the WHATWG URL Standard

Two specifications govern URL parsing. RFC 3986, published in 2005, defines the generic URI syntax and remains the authoritative reference for network protocols. The WHATWG URL Standard, maintained by browser vendors, specifies how web browsers actually parse URLs — including error recovery for malformed input. This tool uses the browser's native URL constructor, which implements the WHATWG standard. This means the parsing results match exactly how Chrome, Firefox, Safari, and Edge interpret the same URL. Key differences from RFC 3986 include: automatic percent-encoding of special characters, normalization of scheme and host to lowercase, and resolution of . and .. path segments.

Query String Encoding

Query parameters follow the application/x-www-form-urlencoded format: key-value pairs separated by & with = between each key and value. Special characters must be percent-encoded (e.g., spaces become %20 or +). The URLSearchParams API handles decoding automatically. Duplicate keys are valid — APIs like Google Search use multiple q parameters, and form submissions with checkboxes produce repeated keys.

Authentication Credentials in URLs

The URL syntax supports embedding credentials as user:password@host. While technically valid per RFC 3986, this practice is deprecated for HTTP and HTTPS. Modern browsers strip or warn about credentials in HTTP URLs due to phishing risks — an attacker could craft a URL like https://google.com@malicious.site/ to mislead users. Credentials remain common in FTP, SSH, and database connection strings (e.g., postgres://user:pass@db.host/mydb). This tool flags URLs containing credentials with a warning badge.

TLD Extraction

The Top-Level Domain (TLD) is the rightmost label of the hostname — .com, .org, .io. Some countries use multi-part TLDs like .co.uk, .com.au, or .ac.jp. This tool recognizes over 70 multi-part TLD patterns to correctly identify the effective TLD. TLD information is useful for cookie scope analysis, domain registration checks, and understanding the jurisdiction governing a website.

Why Use This Tool

URLs are the addressing system of the web. Breaking them into components is a daily task for developers, security analysts, and system administrators. Here are common scenarios:

  • Debugging API calls — Extract the hostname, path, and query parameters from a failing API request to verify each component is correct. Identify misplaced parameters or incorrect percent-encoding.
  • CORS configuration — Extract the origin (protocol + hostname + port) from request URLs to configure Access-Control-Allow-Origin headers correctly. A mismatch in any component causes CORS failures.
  • Cookie scope analysis — Understand which domain and path a cookie applies to. Cookies set for .example.com apply to all subdomains, while path-scoped cookies only match specific URL prefixes.
  • Redirect chain investigation — When debugging redirect loops or incorrect redirects, parse each URL in the chain to identify where the hostname, path, or query parameters change unexpectedly.
  • Security auditing — Detect embedded credentials, identify phishing URLs with misleading userinfo components, and verify that sensitive parameters are not leaked in query strings.

Privacy

All parsing runs entirely in your browser using the native URL constructor. No URLs are transmitted to any server. You can verify this in your browser's Network tab — zero requests are made during parsing. This makes the tool safe for analyzing URLs containing sensitive tokens, API keys, or authentication credentials.

FAQ

What URL components does this tool extract?
The parser extracts protocol (scheme), hostname, port, pathname, search (query string), hash (fragment), username, and password. Query parameters are further split into individual key-value pairs for inspection.
How does this tool parse URLs?
It uses the browser's native URL API, which implements the WHATWG URL Standard. This is the same parser used by Chrome, Firefox, and Safari internally, so the results match exactly how browsers interpret URLs.
What happens if I enter a URL without a protocol?
The tool automatically prepends https:// if no protocol is provided. This mirrors how modern browsers handle bare domain entries in the address bar, ensuring a valid URL for parsing.
Is my URL data sent to a server?
No. All parsing runs entirely in your browser using the native URL constructor. No URLs are transmitted, stored, or logged. You can verify this in your browser's Network tab — zero requests are made during parsing.
NavigateOpenEscClose