URL Parser & Analyzer

Example Input

https://api.github.com/users/octocat/repos?sort=updated&per_page=10#top

Example Output

Protocol:  https:
Hostname:  api.github.com
Port:      443 (default for https, omitted from URL)
Path:      /users/octocat/repos
Fragment:  #top

Query Parameters:
  sort     = updated
  per_page = 10

Full Structure (JSON):
{
  "protocol": "https:",
  "host": "api.github.com",
  "hostname": "api.github.com",
  "port": "",
  "pathname": "/users/octocat/repos",
  "search": "?sort=updated&per_page=10",
  "hash": "#top",
  "origin": "https://api.github.com",
  "href": "https://api.github.com/users/octocat/repos?sort=updated&per_page=10#top",
  "params": {
    "sort": "updated",
    "per_page": "10"
  }
}

Does it support all URL schemes?

Yes. The tool supports all standard URL schemes including https, http, ftp, mailto, file, and custom application schemes like myapp:// or slack://. The scheme is always displayed in the Protocol component of the parsed result. For mailto: URLs, the path component contains the email address and the query string contains optional parameters like subject and body. For file: URLs, the path contains the local file system path.

Can I parse relative URLs?

Relative URLs like /api/v1/users or ../images/photo.jpg cannot be fully parsed on their own because they have no scheme or host component. This tool parses absolute URLs only. To parse a relative URL, combine it with its base URL first to form a complete absolute URL — for example prepend https://yourapp.com to /api/v1/users to get https://yourapp.com/api/v1/users, then paste the complete URL.

Is it safe for sensitive links containing tokens or credentials?

Yes. All URL parsing runs entirely in your browser using the native JavaScript URL API. Your URL — including any authentication tokens, API keys, session IDs, or OAuth codes it contains — is never transmitted to any server, never logged, and never stored. This is important because URLs in authorization flows, webhook signatures, and pre-signed storage URLs often contain sensitive values you would not want processed by a third-party service.

What is the difference between search and query parameters in the output?

The search field in the Full Structure JSON shows the raw query string including the leading ? character — for example ?sort=updated&per_page=10. The params object shows the individual parameters already split and decoded — sort with value updated and per_page with value 10. The search string is the raw value your server receives in the request. The params object is what your server-side framework gives you after parsing that string — for example req.query in Express or request.GET in Django.

Why does the port show as empty even though my URL uses HTTPS?

When a URL uses the default port for its scheme — port 443 for HTTPS or port 80 for HTTP — the port is omitted from the URL and the port field in the parsed output is empty. This is correct behavior per the URL standard. The actual port being used is still 443, but since it is the default it does not appear in the URL string. If your URL uses a non-default port like https://api.example.com:8443/endpoint, the port field will show 8443.

How do I parse URLs in JavaScript, Python, or Go?

In JavaScript (browser and Node.js 10+): const url = new URL('https://example.com/path?key=value') — then access url.hostname, url.pathname, url.searchParams.get('key'), and other properties. This is the same API this tool uses. In Python: from urllib.parse import urlparse, parse_qs then result = urlparse('https://example.com/path?key=value') and params = parse_qs(result.query). In Go: import net/url then u, err := url.Parse('https://example.com/path?key=value') and access u.Host, u.Path, u.Query(). In Ruby: require 'uri' then uri = URI.parse('https://example.com/path?key=value') and URI.decode_www_form(uri.query) for parameters.

What does the origin field mean in the parsed output?

The origin is the combination of scheme, hostname, and port — for example https://api.github.com. It represents the web origin concept used in browser security (the Same-Origin Policy and CORS). Two URLs have the same origin if and only if their scheme, hostname, and port are all identical. https://example.com and http://example.com are different origins (different scheme). https://example.com and https://api.example.com are different origins (different hostname). https://example.com and https://example.com:8443 are different origins (different port). The origin is what browsers compare when deciding whether to block cross-origin requests.

Why does my URL parse differently in the tool than in my application?

This tool uses the WHATWG URL standard (the same standard as JavaScript's URL class and all modern browsers). If your server-side application uses a different URL parsing library — for example Python's urllib which implements RFC 3986 rather than the WHATWG standard — there can be subtle differences in how edge cases are handled, particularly around special characters in hostnames, trailing dots, and certain Unicode characters. For the vast majority of standard URLs, both standards produce identical results. If you see a difference, check whether your server framework's URL parser follows RFC 3986 or WHATWG, and test the specific URL directly in your server code to see what the server actually receives.