Interactive visualizer
URL Anatomy — Visualize Every Part of a URL
Paste any URL and see its scheme, host, port, path, query, and fragment highlighted in color. Every part is annotated with what it does, when it's used, and common pitfalls.
Last updated:
Anatomy
Parts
| Part | Value | Description |
|---|---|---|
| Scheme | https | Protocol used to reach the resource (https, http, ftp, mailto, ws…). Everything before the ':'. |
| Userinfo | (not present) | Optional 'user[:password]@' before the host. Deprecated in browsers for HTTP(S) — Chrome strips it or warns. |
| Host | devkits.vip | Domain name or IP address of the server. Case-insensitive. Wrapped in brackets when it is an IPv6 literal. |
| Port | (not present) | TCP/UDP port on the host. Omitted when it is the scheme default (80 for http, 443 for https). |
| Path | /tools/json-formatter | Resource path on the server, split by '/'. Case-sensitive on most servers. Percent-encoded for special characters. |
| Query | (not present) | Everything after '?' up to '#'. Traditionally 'k=v' pairs separated by '&' — but the RFC allows any format. |
| Fragment | (not present) | Everything after '#'. Not sent to the server — used by the browser to scroll to an anchor or by SPAs for client-side routing. |
Path segments
URL structure at a glance
RFC 3986 defines a URI as scheme://userinfo@host:port/path?query#fragment. Only the scheme is mandatory — everything else is optional depending on the scheme (mailto: URIs have no host, file:// paths have no port, and so on). Browsers apply additional rules on top: the fragment is never sent to the server, and userinfo is deprecated for HTTP(S).
Why parsing URLs by hand is risky
- ▸The '?' in a query value must be percent-encoded, otherwise it starts the fragment early.
- ▸Trailing dots in the host ('example.com.') are legal per DNS but disallowed by some HTTP libraries.
- ▸IPv6 hosts MUST be wrapped in brackets ('[::1]:8080') — forget them and the port becomes ambiguous.
- ▸The path is case-sensitive on most servers; the host is case-insensitive per RFC 3986.
- ▸Percent-encoding is required for reserved characters inside path or query values.
Query string conventions
The RFC does not mandate any format for the query string — everything after ? is just an opaque string. The k=v&k=v form is a convention popularized by HTML forms (application/x-www-form-urlencoded). This visualizer decodes both keys and values with decodeURIComponent and preserves the original order — including duplicate keys.
Frequently Asked Questions
Does this visualizer handle relative URLs?
Yes. The parser is intentionally lenient and accepts inputs without a scheme (e.g. '/api/v1/users?limit=10' or 'example.com/foo'). Anything not present is simply shown as '(not present)' in the parts table.
Why don't you use the browser's URL API?
Native URL() normalizes the input — it lowercases the host, collapses '..' segments in the path, and reorders some query parameters. For a visualizer we want to show exactly what the user typed, so we implement RFC 3986 splitting ourselves.
Is my URL sent anywhere?
No. Parsing is pure JavaScript running in your browser. The URL — including any query parameters that might contain credentials or session tokens — never leaves the page.
How is this different from your URL Encoder/Decoder tool?
The URL Encoder handles percent-encoding of individual strings. This visualizer takes a full URL and breaks down its structure — useful for understanding an unfamiliar endpoint or teaching URL syntax to newcomers.
Other visualizers
Regex Visualizer
Paste a regular expression and see every token color-coded and explained in plain English. Live match preview, capture groups, and syntax hints.
JWT Visualizer
Decode a JWT and visualize the header, payload, and signature side-by-side with plain-English explanations of every registered claim and expiration status.