URLs look simple until you actually have to write code that handles them. Then you discover the path can contain encoded slashes that aren’t slashes, the host can carry a port that the regex didn’t account for, the query string can repeat the same key three times with different values, and the fragment is invisible to the server but very visible to a JavaScript framework. Half the bugs that ship in URL-handling code come from somebody pattern-matching the URL by eye instead of parsing it. PortJar’s URL Parser is the antidote — paste in a URL, see exactly how it decomposes.
What the tool does
URL Parser takes a URL string and breaks it into its standard components: protocol (scheme), host, port, path, query, fragment, and — when present — the userinfo before the host. Each component is shown decoded and labeled, with the query string further broken into its key/value pairs. The breakdown runs entirely in the browser. Nothing is sent to PortJar’s servers and nothing is logged.
The point is to settle arguments quickly. When somebody says “the URL has a ?token= parameter,” paste it into the parser and you’ll see whether the token is in the query, in the fragment (where the server will never see it), or in the path (where it ends up in access logs). The parser does not normalise — what you see is what the URL actually contains, including duplicate keys, empty values, and percent-encoded characters that look harmless until they aren’t.
How to use it
Open portjar.com/tools/url-parser, paste the URL into the input, and read the breakdown below. There is no run button to hit — the parse updates as you type. The page is offline-capable, so you can run it on a URL from a sensitive context (an internal ticket, a customer support session) without anything leaving your browser.
When you’d reach for it
- Debugging a “the token isn’t being sent” bug. Paste the URL the client showed you. If the token is after the
#, the server never sees it — it’s a fragment, which is browser-only. If it’s after the?, it’s a query parameter and the server should see it. The parser settles the question in one screen. - Verifying an SSO callback URL is well-formed. A misplaced
&or a percent-encoded character in the wrong spot will turn a working callback into a redirect-loop or a “state mismatch” error. The parser shows you what the URL actually contains, not what you intended it to contain. - Reading a long signed S3 or CDN URL without losing the plot. Pre-signed URLs cram the signature, expiry, and a stack of query parameters into one line. The parser lays them out so you can confirm the expiry is what you set, the signature is present, and no extra parameter snuck in.
- Catching path-traversal patterns in a customer-supplied URL. Encoded
..segments, double-encoded slashes, and embedded null bytes all show up clearly in the decoded path component. If you’re triaging a suspicious request from a log line, paste the URL here to read it without guessing. - Reviewing a redirect target before publishing it. When a campaign or vendor hands you a URL to redirect to, the parser tells you exactly where it goes. A path of
/track/click?dest=…should be a clue that the URL is a tracker wrapping the real destination.
What to make of the output
The protocol and host are obvious; the parts that bite are the ones below. Watch the port. An explicit port other than 80 or 443 in a public-facing URL is either intentional or a leak — either way, worth confirming. A missing port doesn’t mean port 80 or 443; it means the default for the scheme, which is the same thing, but worth saying out loud when you’re explaining the URL to somebody.
The path is the part most prone to misreading. Trailing slashes matter for some frameworks and not others, so don’t normalise silently. Encoded slashes (%2F) in the path are not the same as real slashes and are explicitly disallowed by some web servers — if the parser shows one, that’s a finding.
The query string is the most common source of “but the URL looks fine” bugs. Each key/value pair is shown separately. If the same key appears twice, the parser shows it twice — different frameworks pick the first, the last, or the array, and the difference matters. Empty values (?foo=) are not the same as missing keys (?) and not the same as keys with no value (?foo); the parser shows the distinction.
The fragment is invisible to the server. If something the server is supposed to receive is sitting in the fragment, the bug is on the client.
For environments where URL shape, redirect hygiene, and CDN behaviour need to stay consistent across many sites, Stack Harbor handles that as part of Environment Management as a Service.