URL Inspector

What this checks

This combines a full component breakdown (like URL Parser) with an encoding audit and a set of automatic findings, so you don't have to eyeball a suspicious or malformed URL by hand:

• Scheme and credentials. Flags plain http:, and — more importantly — a user:pass@ prefix, since text before an @ is not the host. https://accounts-google.com@evil.example/ actually requests evil.example, with accounts-google.com just along for the ride as a (fake) username. This is a real phishing pattern, not a hypothetical one.
• Punycode hosts. An xn-- hostname is a valid encoding for an internationalized domain, but it's also how homograph domains (visually identical to a real one in another script) get built.
• Path traversal. Checks the raw input for .. segments, literal or percent-encoded — the browser's own URL parser already resolves these out of the path it hands back, but code that skips that resolution and works with the raw string directly won't get that protection for free.
• Encoding problems. A malformed % sequence, or a value that's been percent-encoded twice (%2520 instead of %20) — often the result of a value passing through more than one layer of encoding by mistake.
• Open-redirect-shaped parameters. A parameter named something like redirect or next whose value is itself a URL — worth confirming it's checked against an allowlist if it drives a server-side redirect.

The decoded preview renders every part — path, query values, fragment — fully human-readable in one line. It's a reading aid, not a URL you should paste back anywhere; use URL Builder to construct a real one.

FAQ

Why does the pathname shown not have the .. I typed?

The URL parser resolves dot-segments as part of normalizing the URL, before this tool ever sees pathname — that's standard, spec-defined behavior, not something this tool does. The traversal finding checks the input you typed, not the normalized result.

Is a punycode or userinfo finding proof something is malicious?

No — both have legitimate uses. They're flagged because they're also the mechanism behind two real, common URL-spoofing techniques, so they're worth a second look, not an automatic red flag.