URL Parser Differential Checker
Paste one URL, or several (one per line), and see exactly where the browser/WHATWG URL parser and older RFC 3986-style parsers used by some backend languages would disagree about what the URL actually points at — and why that's sometimes a real security problem, not just a formatting quirk.
Processed locally in your browser. Your file is never uploaded.
How to use this calculator
- Paste a single URL, or a longer block with one URL per line — nothing leaves your browser.
- Select "Check URLs".
- Review each flagged value: which parsing behavior diverges, which parsers are affected, and why it matters.
- Use the suggested rewrite where one is offered — userinfo confusion and non-ASCII hosts are left unresolved deliberately, since guessing the intended host would be worse than flagging the ambiguity.
Assumptions
- Each non-blank line is treated as one whole URL, not scanned for URL-shaped tokens embedded in longer text — several of these checks (embedded whitespace, backslash position, userinfo) depend on analyzing the full string, not a fragment of it.
- A line with no scheme ("https:") and no protocol-relative "//" prefix is treated as plain text and skipped, not reported as an issue.
- The WHATWG side of every comparison is the actual browser `URL` constructor running in your browser right now, not a simulation of it — so "unaffected" for that column means this exact input was tried against it.
- The RFC 3986-strict/legacy side is a description of well-documented behavior in older or stricter parsers, not a live second parser — this tool doesn't execute untrusted code from another language to test against.
Methodology
Each candidate URL is checked against seven well-documented, independent divergences between lenient WHATWG-style parsing and stricter RFC 3986-style parsing: backslash normalization, userinfo/host confusion, extra leading slashes, non-ASCII/IDN hosts, missing-scheme protocol-relative URLs, embedded whitespace/control characters, and unencoded spaces. A rewrite is offered only where it's unambiguously safe — normalizing backslashes, stripping stray whitespace, collapsing extra slashes, and percent-encoding a literal space. Userinfo confusion and non-ASCII hosts are never auto-rewritten, since the tool can't know which host was actually intended.
Worked example
Userinfo `@` confusion
Inputs: https://trusted.com@evil.com/
Result: A browser reads everything before the "@" as userinfo and everything after as the real host, so this URL actually points at evil.com, not trusted.com. Flagged as an error — this is a classic bypass for code that checks a URL's target with string matching instead of a real URL parser.
Backslashes instead of forward slashes
Inputs: https:\\example.com\path
Result: Browsers normalize backslashes to forward slashes for special schemes like https, so this parses identically to https://example.com/path in a browser — but many non-browser parsers don't perform that normalization and will parse a different host, or fail outright. Flagged as an error and safely rewritten to https://example.com/path.
Extra leading slashes
Inputs: https:///example.com
Result: Three slashes after the scheme colon are handled inconsistently across parsers. Flagged as a warning and safely rewritten to the canonical https://example.com.
Practical guidance
- Never validate a URL's trust or origin with string matching (`url.startsWith(...)`, `url.includes(...)`) — always parse it with a real URL library first and check the parsed host.
- Normalize backslashes to forward slashes before a URL reaches any parser that doesn't perform that normalization itself — treat a backslash in a URL as a red flag, not a formatting choice.
- Prefer an explicit scheme over a protocol-relative URL in anything that will be parsed by more than one system, since not every parser accepts a protocol-relative value without a supplied base.
Common mistakes
- Assuming that because a URL "looks like" it points at a trusted domain, it actually does — userinfo confusion is specifically designed to defeat a quick visual or substring check.
- Treating a URL that parses without throwing as proof it was interpreted correctly — several of these divergences (userinfo, backslashes, non-ASCII hosts) parse successfully everywhere, just to a different host or path depending on the parser.
FAQs
Why is userinfo confusion flagged as an error but a non-ASCII host only a warning?
Userinfo confusion is a well-documented, actively exploited security bypass with no legitimate common use case matching this shape. A non-ASCII host is often completely legitimate (an internationalized domain name) — the issue is purely that parsers disagree on how to handle it, not that the URL itself is suspicious.
Why doesn't the tool just fetch or normalize the URL to check which host it really points to?
This tool never navigates to, fetches, or renders any pasted URL as a clickable link — it only performs static text analysis in your browser, on purpose, since a tool that teaches URL-confusion attack patterns must not become a vector for one.
Does a clean result mean the URL is definitely safe?
It means none of the seven specific, well-documented parsing divergences this tool checks for were found — not that the URL is safe to fetch, or that it isn't malicious in some other way unrelated to parser disagreement.