//: # ()
Want to see this applied to a real URL? Use our free Online URL Parser & Explainer — paste any URL and get every part color-coded and explained instantly.
A URL (Uniform Resource Locator) looks like one string, but it's actually a small, strictly-ordered document made of several distinct fields. Browsers, HTTP clients, and API gateways all parse it the same way, defined by RFC 3986. Once you can read it field-by-field, debugging broken API calls, weird redirects, and CORS errors gets a lot easier.
Take this example:
https://user:pass@sub.example.com:8443/path/to/resource?search=hello&page=2#section-2That single line contains seven distinct parts. Let's go through each one.
https:The scheme tells the client how to interpret everything that follows and which protocol to speak — https for encrypted HTTP over TLS, http for plain HTTP, plus non-web schemes like mailto:, ftp:, ws:/wss: for WebSockets, or custom app schemes like myapp://. If a URL doesn't start with a scheme, most parsers (including the browser) will refuse to treat it as absolute.
Practically: always check this first when debugging "mixed content blocked" errors — it almost always means an https: page tried to load an http: resource.
user:pass@This is the oldest and least-used part of a URL — a way to embed a username and, optionally, a password directly in the address for HTTP Basic Authentication. It's technically valid, but you should avoid it: credentials placed here end up in shell history, server access logs, browser history, and Referer headers sent to third-party resources on the page. Most modern browsers now hide or strip this section from the address bar entirely, and some (Chrome included) refuse to navigate to URLs containing it for common web ports.
sub.example.comThe host identifies the server — either a domain name or a literal IP address (IPv4 or bracketed IPv6, like [::1]). For a domain name, it further breaks down into a registrable domain (example.com) and an optional subdomain (sub). This is the piece DNS actually resolves to an IP address before any connection is made.
:8443The port is the specific TCP endpoint on that server. If it's omitted, the client uses the scheme's default — port 80 for http, 443 for https. You'll see an explicit port most often when talking to a local dev server (localhost:3000), a non-standard API gateway, or an internal service that isn't fronted by a standard reverse proxy.
/path/to/resourceThe path identifies a specific resource on the server as a sequence of /-separated segments. Unlike a filesystem path, these segments are just a routing convention — a REST API might map /users/42/orders straight to a database query rather than a real folder structure. Case sensitivity of the path depends entirely on the server, not the URL spec.
?search=hello&page=2Everything after ? is a flat list of key/value pairs, traditionally encoded like an HTML form submission (key=value, pairs joined with &, special characters percent-encoded). This is where most of the dynamic information in a request lives — search terms, pagination, filters, API keys passed as parameters, tracking IDs. It's sent to the server and typically logged, so it's not the place for anything sensitive.
#section-2The fragment is the only part of a URL that never leaves the browser — it's not sent to the server at all. Originally designed to jump to an anchor within a page, it's now heavily reused by single-page apps for client-side routing and state (#/dashboard/settings), since changing it doesn't trigger a full page reload.
Understanding this breakdown solves a handful of recurring, very avoidable bugs:
#, since fragments are client-side only.Paste any real URL — including your own API endpoints — into the URL Parser & Explainer and every part is color-coded and explained live, entirely in your browser. Nothing you paste is uploaded anywhere.