Analizador de URL

What is URL Parsing?

URL parsing is the process of decomposing a Uniform Resource Locator into its individual structural components as defined by RFC 3986 and the WHATWG URL Standard. A complete URL can contain up to eight distinct parts: scheme (protocol), userinfo, host, port, path, query string, and fragment. This tool parses all of these components simultaneously, giving you a full anatomical breakdown of any URL — unlike a query string parser which only handles the key-value pairs after the ? character. Understanding URL structure is essential for debugging routing issues, validating API endpoints, configuring CORS policies, and constructing URLs programmatically.

Full URL Anatomy: The Eight Components

Every URL follows a structured syntax defined by RFC 3986. The general form is: scheme://userinfo@host:port/path?query#fragment. Each component serves a specific purpose in resource identification and retrieval:

• Scheme (Protocol): Identifies the protocol — https, http, ftp, ssh, file, or custom schemes like mailto and tel. The scheme determines how the rest of the URL is interpreted and which default port applies.
• Authority: The section between // and the path. It contains the optional userinfo, the mandatory host, and the optional port. Together these identify the server responsible for the resource.
• Userinfo: Credentials embedded in the URL, formatted as username:password@. This pattern is deprecated for HTTP/HTTPS due to security concerns (credentials visible in logs and referrer headers) but still valid for protocols like FTP and SSH connection strings.
• Host: A registered domain name (api.example.com), an IPv4 address (192.168.1.1), or an IPv6 address enclosed in brackets ([::1]). The WHATWG URL Standard normalizes hosts to lowercase and applies IDNA (Internationalized Domain Names) encoding for non-ASCII characters.
• Port: A TCP port number (0–65535). When omitted, the default port for the scheme applies: 80 for HTTP, 443 for HTTPS, 21 for FTP. The WHATWG parser strips default ports during normalization.
• Path: A hierarchical sequence of segments separated by / that identifies the specific resource on the host. Paths can be absolute (/api/v2/users) or relative. Percent-encoded characters are preserved in the raw path but decoded for display.
• Query: The portion after ? and before #, typically containing key-value pairs separated by &. While this tool shows you the raw query string as a component, it does not deeply parse individual parameters — that is the domain of a dedicated query string parser.
• Fragment: The portion after #, identifying a secondary resource within the primary document (an anchor, section ID, or client-side routing state). Fragments are never sent to the server — they are processed entirely by the client.

This tool parses all eight components in a single operation, presenting them in a structured table. This gives you immediate visibility into how a URL will be interpreted by browsers, HTTP clients, and server-side routing frameworks.

The JavaScript URL API and WHATWG Standard

Modern browsers and Node.js implement the URL constructor defined by the WHATWG URL Standard. This API provides a standardized, spec-compliant way to parse and manipulate URLs programmatically:

The URL constructor accepts a string and returns an object with properties for each component: protocol, username, password, hostname, port, pathname, search, hash, and the composite origin. It also provides searchParams — a URLSearchParams instance for iterating over query parameters.

The WHATWG URL Standard differs from RFC 3986 in several practical ways. The WHATWG spec performs percent-encoding normalization, applies Punycode conversion for internationalized domains, strips default ports, and resolves relative paths against a base URL. It also defines specific "special schemes" (http, https, ftp, file, ws, wss) that enforce stricter syntax rules — for example, special-scheme URLs always require an authority component. This tool uses the WHATWG parsing algorithm internally, so the results match exactly what browsers and server runtimes produce when processing URLs.

When the URL constructor receives an invalid URL, it throws a TypeError rather than returning a partial result. This strict validation behavior makes it suitable for input validation — if a string parses successfully, it is guaranteed to be a well-formed URL according to the WHATWG specification.

URL Parser vs Query String Parser: Key Differences

This URL parser and a query string parser operate at different levels of URL decomposition. Understanding when to use each tool prevents debugging time and incorrect assumptions:

• Scope: This URL parser breaks down the entire URL structure — scheme through fragment — into its RFC 3986 components. A query string parser focuses exclusively on the ?key=value&key2=value2 portion, treating it as a flat or nested key-value map.
• Input: This tool accepts a full URL (e.g., https://api.example.com:8080/v2/users?role=admin&active=true#results) and shows every component. A query string parser accepts just the query portion (role=admin&active=true) or the full URL but only outputs the parsed parameters.
• Depth: This tool gives you the raw query string as a single component. A query string parser goes deeper — it splits on &, decodes percent-encoded keys and values, handles + as space, and can reconstruct nested objects from bracket notation (filter[status]=active).
• Use case: Use this URL parser when you need to verify the host, port, or path of a URL, debug routing issues, validate URL structure, or understand how a URL will be split by the URL constructor. Use a query string parser when you need to extract, modify, or reconstruct individual query parameters.

In practice, these tools are complementary. Parse the full URL first to confirm the structure is correct, then use a query string parser to work with individual parameters if needed.

Common URL Parsing Pitfalls

Developers frequently encounter these URL parsing issues that this tool helps diagnose:

• Port confusion: Forgetting that https://example.com implicitly uses port 443. The WHATWG parser omits default ports from the serialized URL, which can cause string comparison failures if you manually append :443.
• Fragment leakage: Assuming the server receives the fragment. Since fragments are client-only, passing state via # requires client-side JavaScript to extract and forward it.
• Double encoding: Encoding an already-encoded URL creates sequences like %2520 (space encoded twice). This tool shows you the raw path and query so you can spot double-encoding immediately.
• Trailing slashes: /api/users and /api/users/ are different paths. Many servers treat them identically via redirects, but not all — this tool makes trailing slashes visible.
• IPv6 bracket requirement: IPv6 addresses must be enclosed in brackets within URLs (http://[::1]:3000/). Omitting brackets causes the colons in the address to be misinterpreted as port separators.

Code Examples

Parsing URLs with the WHATWG URL API

// Parse a complete URL into its components
const url = new URL('https://admin:secret@api.example.com:8443/v2/users?role=admin&active=true#results');

console.log(url.protocol);   // "https:"
console.log(url.username);   // "admin"
console.log(url.password);   // "secret"
console.log(url.hostname);   // "api.example.com"
console.log(url.port);       // "8443"
console.log(url.pathname);   // "/v2/users"
console.log(url.search);     // "?role=admin&active=true"
console.log(url.hash);       // "#results"
console.log(url.origin);     // "https://api.example.com:8443"

// Validate URL structure — throws TypeError on invalid input
try {
  new URL('not-a-valid-url');
} catch (e) {
  console.error('Invalid URL:', e.message);
}

Constructing and modifying URLs programmatically

// Build a URL from components
const base = new URL('https://api.example.com');
base.pathname = '/v3/search';
base.searchParams.set('q', 'javascript url parsing');
base.searchParams.set('limit', '25');
base.hash = 'results';

console.log(base.href);
// → "https://api.example.com/v3/search?q=javascript+url+parsing&limit=25#results"

// Resolve relative URLs against a base
const relative = new URL('/docs/api.html', 'https://example.com/old/page');
console.log(relative.href);
// → "https://example.com/docs/api.html"

Standards & Specifications

• WHATWG URL Standard — Living standard defining URL parsing, serialization, and the URL API used by browsers and Node.js
• RFC 3986 — Uniform Resource Identifier (URI) generic syntax — defines the component structure (scheme, authority, path, query, fragment)
• RFC 3987 — Internationalized Resource Identifiers (IRIs) — extends URI syntax to support Unicode characters in domain names and paths