URL Parser

The URL Parser deconstructs any URL into its component parts according to the RFC 3986 specification, showing exactly how browsers and HTTP clients interpret each segment. Paste a URL like https://www.example.com:8443/api/v2/users?status=active&limit=50#results and see each component extracted: scheme, host, port, path, query parameters, and fragment.

Understanding URL Structure

URLs are the addresses of the web, but their structure is more nuanced than most developers realize until they run into a parsing edge case. A URL is not just "the thing you type in the browser" -- it is a precisely defined format specified in RFC 3986, with rules about which characters are allowed where, how special characters must be encoded, and how each component is delimited from the next. Getting these details wrong causes real bugs: broken redirect chains, misrouted API calls, security vulnerabilities from URL confusion, and analytics tracking failures from lost query parameters.

The basic structure of a URL is scheme://userinfo@host:port/path?query#fragment, but most URLs omit several of these components. The scheme tells the client which protocol to use (http, https, ftp). The host identifies the server, either as a domain name or an IP address. The port is usually implicit -- 443 for HTTPS, 80 for HTTP -- but can be specified explicitly when a service runs on a non-standard port. The path identifies the specific resource on that server. The query string carries parameters as key-value pairs. And the fragment points to a specific section within the resource, processed entirely by the client and never sent to the server.

What trips people up are the edge cases. A URL can contain credentials (user:password@host), though this is deprecated for HTTP. IPv6 addresses must be enclosed in brackets ([2001:db8::1]). Query parameter values can themselves contain ? and = characters if they are percent-encoded. The first ? separates path from query, but subsequent ? characters are literal parts of the query. This parser handles all of these cases and displays each component separately, making the URL's structure unambiguous.

How to Parse a URL into Components

1. Paste any complete URL into the input field
2. The parser extracts each component: scheme, userinfo, host, port, path, query, fragment
3. Query strings are further broken down into individual key-value parameter pairs
4. Default ports are identified based on the scheme (e.g., 443 for https)
5. Any encoding issues or non-standard constructions are highlighted

URL Parsing Examples

Standard HTTPS URL

Input: https://www.example.com:8443/api/v2/users?status=active&limit=50#results

Query Parameters:

URL with Authentication

Input: ftp://admin:[email protected]/pub/reports/2024/

URL with IPv6 Host

Input: http://[2001:db8::1]:8080/index.html

Complex Query String

Input: https://search.example.com/results?q=url+encoding&lang=en&page=3&sort=relevance

Query Parameters:

When to Use the URL Parser

• Debugging redirect chains to inspect each URL in the sequence and identify where parameters are lost or modified
• Analyzing OAuth callback URLs to verify redirect URIs, state parameters, and authorization codes
• Extracting query parameters from long URLs in webhook payloads, analytics tracking links, or API responses
• Inspecting deep links in mobile applications to understand routing and parameter passing
• Security analysis of potentially malicious URLs to identify obfuscation in the host, path, or query components
• Comparing URLs to determine whether two URLs that look different actually point to the same resource

How URL Structure Works (RFC 3986)

The URL Anatomy

A URL follows this general structure:

scheme://userinfo@host:port/path?query#fragment

Each component serves a specific purpose:

• Scheme -- identifies the protocol (http, https, ftp, ssh, mailto)
• Userinfo -- optional credentials (user:password@), deprecated for HTTP/HTTPS
• Host -- domain name (example.com) or IP address (192.0.2.1 or [2001:db8::1])
• Port -- optional TCP port number; defaults depend on scheme (80 for HTTP, 443 for HTTPS)
• Path -- hierarchical resource identifier (/api/v2/users)
• Query -- key-value parameters after ?, separated by & (status=active&limit=50)
• Fragment -- client-side anchor after #, not sent to the server (#section-2)

Percent Encoding

Special characters in URLs must be percent-encoded using % followed by two hexadecimal digits. Common encodings:

Default Ports by Scheme

When the default port is used, it is typically omitted from the URL. The parser identifies both explicit and implicit ports.

URL Parsing in Practice

The most common reason developers reach for a URL parser is debugging. You are looking at a redirect chain and the final URL is missing a query parameter that was present in the original. Was the parameter dropped by the redirect? Was it renamed? Was it absorbed into the path? Parsing each URL in the chain side by side reveals exactly where the parameter disappeared. This is especially common in OAuth flows, where redirect URIs carry state parameters, authorization codes, and scope values that must survive multiple redirects intact.

Another frequent use case is API integration work. When you receive a webhook payload or a callback URL from a third-party service, you need to extract specific query parameters to process the event. The URL might be deeply nested in a JSON response, URL-encoded within another URL, or truncated in a log file. Parsing it into components gives you clean access to each parameter without manual string splitting that breaks on edge cases like encoded & characters within parameter values.

For security analysis, URL parsing reveals obfuscation techniques that are invisible when looking at the raw URL. An attacker might use an encoded @ character (%40) to make a URL appear to point to a trusted domain when it actually authenticates to a malicious one. Or they might use encoded path separators to bypass path-based access controls. Parsing the URL with a standards-compliant parser shows the true structure after decoding, making these techniques visible.

Frequently Asked Questions

Why does the fragment not get sent to the server?

The fragment identifier (everything after #) is processed entirely by the client (browser). It is stripped from the URL before the HTTP request is made. The server never sees the fragment. This is defined in RFC 3986 and is used for client-side navigation within a page, single-page application routing, and anchor links.

How does the parser handle URLs with multiple ? or # characters?

Per RFC 3986, only the first ? separates the path from the query, and only the first # (after the query) separates the query from the fragment. Additional ? characters within the query are treated as literal characters. Additional # characters within the fragment are also literal. The parser follows this standard behavior.

Can the parser handle internationalized domain names (IDN)?

Yes. Internationalized domain names like beispiel.de (with umlauts or non-ASCII characters) are displayed as-is and the parser also shows the Punycode encoding (e.g., xn--bsp-jma.example.com) that is used in the actual DNS lookup.

What is the difference between %20 and + for spaces?

Both represent a space character, but they are used in different contexts. %20 is the standard percent-encoding for a space and is valid anywhere in a URL. The + encoding for spaces is specific to the application/x-www-form-urlencoded format used in HTML form submissions and query strings. In the path component, + is a literal plus sign, not a space. The parser handles both encodings correctly based on their context.

How do I tell if two different URLs point to the same resource?

Parse both URLs and compare their components. URLs that differ only in default port (e.g., http://example.com vs http://example.com:80), trailing slashes, query parameter order, or encoding differences may resolve to the same resource. Use the URL Normalizer to canonicalize URLs before comparison.

Why does my URL parse differently in different programming languages?

Different URL parsing libraries may handle edge cases differently. Python's urllib.parse, JavaScript's URL constructor, and Go's net/url generally follow RFC 3986 but can diverge on malformed URLs, relative references, or unusual encoding patterns. This parser follows the RFC 3986 specification strictly and is useful as a reference implementation to compare against your language's parser.

Related Tools

• URL Normalizer - Normalize URLs by removing defaults and sorting params
• Query String Parser/Builder - Parse and build URL query strings
• Port Validator - Validate port numbers (0-65535)
• HTTP Header Formatter - Convert between raw and key/value header formats
• Bulk Add/Remove Query Params - Add or remove query parameters from multiple URLs