URL Parser & Builder
Parse URLs into 8 components with query-string table and IDN/punycode detection. Build URLs from parts. Relative resolver.
Resolved
Query parameters
| Key | Value |
|---|---|
No query parameters.
About this tool
URL Parser & Builder decomposes any URL into its eight RFC 3986 components — scheme, userinfo, host, port, path, query, fragment, and the original-encoded form — and presents them in an editable form. Change any field and the assembled URL updates instantly. The query string is shown as a table of name/value pairs, with proper percent-encoding applied to special characters.
The tool also handles the related operations: punycode/IDN detection on the host (a xn-- label decodes to its Unicode form, a Unicode host encodes to xn--), relative-URL resolution against a base (apply ../foo?bar to https://example.com/a/b/c and get https://example.com/a/foo?bar), and validation against the WHATWG URL specification (which is stricter than RFC 3986 in some areas, notably authority parsing).
When to use this tool
- Debugging URL handling. A redirect that arrives as
%25instead of%— find the double-encoding step in your stack. - Building safe links. Construct URLs from user input with proper escaping instead of string concatenation.
- Verifying a suspicious URL. Decode obfuscated
%2E%2Etraversal attempts, IDN homograph tricks, and userinfo phishing in plain view. - Working with OAuth and redirects. Confirm
redirect_uriparameters are encoded correctly before the auth server rejects them.
About percent-encoding
RFC 3986 reserves a handful of characters with structural meaning (:/?#[]@!$&'()*+,;=). Inside path segments and query values they must be percent-encoded when they appear as data rather than syntax. Modern URL parsers do this automatically; manual string concatenation does not. If you find yourself writing "?key=" + value in code, you almost certainly have an injection bug — use URLSearchParams or our builder instead.
Frequently asked questions
What is the difference between userinfo and the path?
:// and the host: https://user:[email protected]/path. It is technically legal in URLs but Chrome / Firefox strip it from the address bar to prevent phishing (https://[email protected]). Modern HTTP clients warn or refuse it. If you need credentials in a URL, encode them properly and prefer Authorization headers instead — userinfo in URLs is a security smell.
Why do my query-string values come back with %20 instead of spaces?
%20 (percent-encoding) or + (the older form-urlencoded variant for query strings). Both decode to a space on the server. %20 is the universal form; + only works inside query strings, never in paths. Our builder uses %20 everywhere for safety.
How does relative URL resolution work?
./ and ../ in the resulting path. Examples: ../x applied to /a/b/c/d gives /a/b/x; //other.com/path applied to anything gives //other.com/path (a "scheme-relative" reference). Our tool runs this algorithm and shows the resolved URL.
Does the parser detect IDN homograph attacks?
xn-- labels) and decodes them to Unicode, so you can see which characters are actually present. A "google.com" with a Cyrillic о instead of Latin o will decode to a Unicode form that visibly contains the look-alike. Combine with the Punycode tool for a deeper inspection; modern browsers also display these in the address bar.