Paste any URL into this tool and it splits into pieces that browsers, servers, and JavaScript routers each treat completely differently — which is exactly why "just read the URL" bugs are so common in web development.
The parts of a URL
- Scheme —
https://, tells the browser how to connect. - Host —
api.example.com, the domain name or IP address being contacted. - Port — optional, defaults to 443 for HTTPS and 80 for HTTP.
- Path —
/v2/orders/48213, the specific resource on that server. - Query string — after
?, key-value pairs like?page=2&sort=desc. - Fragment — after
#, client-side only.
The fragment is where client-side routing hides
Single-page apps built with older hash-based routers (think example.com/#/settings/profile) rely on the fact that the fragment never leaves the browser — changing it doesn't trigger a page load, so the app's JavaScript can intercept it and render a different view instantly. Modern frameworks mostly use the History API to get clean paths instead, but hash routing still shows up in embedded widgets and older SPAs, and it's a common source of confusion when a URL "has a route in it" that a server-side redirect or analytics tool can't see at all.
Query strings are a REST API's real interface
For anyone working with REST endpoints, the query string is often more important than the path — pagination (?page=, ?limit=), filtering (?status=active), and sorting (?sort=-created_at) are usually passed there rather than in the path itself. Splitting a long API request URL into its parameters is often faster than reading API docs to figure out what a request is actually asking for.
Why encoding trips people up
Each part of a URL has its own rules for which characters need escaping. & is safe in a path but splits parameters in a query string, so a literal & inside a parameter's value has to be encoded as %26 — miss that and the parameter silently gets cut short instead of throwing an error.
The userinfo phishing trick
A link like https://accounts.google.com@evil.com/ looks like it goes to accounts.google.com, but the browser actually opens evil.com — everything before the @ is a username (userinfo), not the host. It's a classic way to disguise a phishing link as a trusted domain, which is why most browsers now flag or strip userinfo from the address bar, and why some URL shorteners refuse to shorten links that contain it at all.