URL Parser for Host, Path and Query Parameters
Parse a URL into its protocol, host, port, path, query parameters, and fragment. Compare encoded and decoded values while debugging a link.
URL Parser workspace
| Protocol | https: | |
| Origin | https://www.toolk.site | |
| Hostname | www.toolk.site | |
| Port | 443default for https | |
| Pathname | /tools/url-parser | |
| Search | ?utm_source=newsletter&utm_medium=email&ref=top | |
| Hash | #features | |
| Full href | https://www.toolk.site/tools/url-parser?utm_source=newsletter&utm_medium=email&ref=top#features |
| # | Key | Value (decoded) | Raw value |
|---|---|---|---|
| 1 | utm_source | newsletter | newsletter |
| 2 | utm_medium | ||
| 3 | ref | top | top |
WHATWG URL Standard
Parser uses the same algorithm browsers use natively for every link and fetch — no homebrew regex, no edge-case bugs around IPv6, userinfo, or trailing slashes.
Query Parameters as Table
Search string split into key-value rows with both raw and decoded values shown. Spot double-encoding, repeated keys, and trailing whitespace at a glance.
Path Segments + Defaults
Path split into individual segments. Default ports (80 for HTTP, 443 for HTTPS, 21 for FTP) shown explicitly even when omitted from the URL string.
100% Client-Side
URLs often contain auth tokens, customer IDs, or internal hostnames. They never leave your browser. No fetch, no XHR.
URL Parser: break any URL into its components
Parse a URL into its protocol, host, port, path, query parameters, and fragment. Compare encoded and decoded values while debugging a link. Parsing identifies a URL's components; it does not approve the destination for redirects or server requests. Validate the scheme and destination against your application's rules. Repeated query parameters and encoded characters need explicit handling by the system that consumes them.
How to use the URL parser
- Paste a complete, absolute URL (it must start with a scheme such as
https://orpostgres://) into the input. - Read the component breakdown — protocol, hostname, port, path, search, and hash — each isolated on its own line.
- Scan the query parameters table: every key-value pair is a row, with the decoded value next to the raw percent-encoded string.
- Check the path segments chips to confirm REST resource parts like
/users/123/orderssplit correctly. - Use a sample URL (UTM link, GitHub API, Postgres URI, encoded path) to see how each component behaves, then copy any field or all params as JSON.
What is in a URL, and how does parsing work?
The generic syntax of a URL is defined by RFC 3986 as scheme://userinfo@host:port/path?query#fragment. Browsers parse with the WHATWG URL Standard, which refines RFC 3986 for the real web: it supports Unicode hosts via IDNA and, instead of rejecting an illegal character, percent-encodes it and continues. RFC 3986 has neither behavior — it has no IDNA and stops parsing on an invalid character. This tool calls the same native new URL() constructor browsers use for every navigation, fetch, and link, so a URL that parses here parses identically everywhere.
Query strings are read with URLSearchParams, the application/x-www-form-urlencoded parser. It walks the string after ?, splits on & then =, and exposes .get(key) for the first value and .getAll(key) for every value of a repeated key. Because it follows form-encoding rules, it decodes a + to a space — a subtlety covered in the examples below.
Worked examples: input → parsed
UTM marketing link
https://toolk.site/tools/url-parser?utm_source=newsletter&ref=top#features
protocol https:, hostname toolk.site, port 443 (default, shown explicitly), path /tools/url-parser, two params (utm_source=newsletter, ref=top), fragment #features.
Database connection URI (userinfo + explicit port)
postgres://user:p%[email protected]:5432/myapp_production?sslmode=require
username user, password masked, hostname db.example.com, port 5432, path /myapp_production. The password p%40ssw0rd decodes to p@ssw0rd — the @ had to be encoded as %40 so it wasn't mistaken for the userinfo separator.
Repeated query key
https://example.com/search?tag=red&tag=blue&tag=green
The table shows three separate rows, all keyed tag. In code, .get("tag")returns only "red" (the first), while .getAll("tag") returns ["red", "blue", "green"].
Edge case · + vs %20 in a query value
Given ?q=hello+world, the query-string parser (URLSearchParams) reads the value as hello world because form-encoding treats + as a space. But decodeURIComponent("hello+world") leaves the + intact — only %20 decodes to a space there. So the same value can look right in one view and wrong in another. To send a literal plus sign, encode it as %2B.
The seven URL components (RFC 3986 / WHATWG)
| Component | Example | Spec | Notes |
|---|---|---|---|
| scheme | https | URL Standard §3.1 | Protocol identifier. Common: http, https, ftp, mailto, ws, wss, file, data. |
| userinfo | user:password | URL Standard §3.2 | Authentication credentials (deprecated in URLs — use Authorization header instead). |
| host | www.example.com or 192.0.2.1 | URL Standard §3.3 | DNS hostname or IP address. IPv6 wrapped in square brackets. |
| port | 443 | URL Standard §3.4 | TCP port. Omitted when matching the default for the scheme. |
| path | /tools/url-parser | URL Standard §3.5 | Slash-separated hierarchical resource identifier. |
| query | utm_source=newsletter&ref=top | URL Standard §3.6 | After ? — typically key=value pairs joined by & (the application/x-www-form-urlencoded convention). |
| fragment | #features | URL Standard §3.7 | Client-side anchor. NEVER sent to the server in HTTP requests. |
The WHATWG URL Standard supersedes RFC 3986 for web URLs — browsers diverged from 3986 in incompatible ways years ago, and the WHATWG spec codified what actually works.
When a URL parser is the right tool
Debug analytics tags
Inspect UTM parameters in marketing links — utm_source, utm_medium, utm_campaign, utm_content, utm_term.
Validate redirects
Parse redirect chain URLs to verify the destination, query preservation, and any query-parameter injection.
Debug Open Graph URLs
Check what URL a Facebook / Twitter / LinkedIn scraper actually fetches when previewing a link.
Audit query injection
Spot accidentally-double-encoded values or trailing whitespace before they cause API errors.
Extract path parameters
Split /users/123/orders/456 into resource segments for REST API testing.
Manipulate search params
Add, remove, or change query parameters and rebuild the canonical URL.
The default-port and empty-segment behavior most parsers hide
The native URL object returns an empty string for .port when the port matches the scheme default, so a plain https://example.com reports no port at all. This tool fills that gap from a built-in map — http → 80, https → 443, ws → 80, wss → 443, ftp → 21 — and shows the implicit port explicitly, so you always know which port a request actually targets.
Two more real behaviors worth knowing. First, path segments are produced with pathname.split('/').filter(Boolean), so empty segments are dropped — /a//b/ yields just a and b, not five entries. Second, the decoded-value display uses decodeURIComponent wrapped so a malformed escape (a lone % or %zz) does not throw; it falls back to showing the raw string unchanged. That is exactly the signal of a double-encoding bug: if the "decoded" value still contains % sequences, something upstream encoded twice.
Related encoder & crypto tools
Percent-encode or decode individual values
JSON FormatterInspect API response bodies after a request
JWT DecoderDecode tokens that appear in callback URLs
Base64 EncoderEncode data carried in query strings
Base64 DecoderDecode Base64 tokens and payloads
HMAC GeneratorSign URLs and verify webhook signatures
Hash GeneratorSHA-256 / MD5 checksums for URL params
Image to Base64Inline images as data URIs in a URL
Base64 to ImagePreview a data-URI image from a URL
Guide: JWT Structure ExplainedHow tokens in callback URLs are built
All Online ToolsBrowse the full Toolk tool hub
Last updated: September 15, 2026 · Runs 100% in your browser — no uploads, tool input is not sent to Toolk.
Frequently asked questions
Why does my relative path fail to parse?
The WHATWG URL constructor requires an absolute URL with a scheme, so a bare /path?query=1 throws an Invalid URL error — prefix it with any origin such as https://example.com and it parses. This mirrors real browser behavior, where a relative reference only resolves against a base.
Why does the port field sometimes show a number I never typed?
The native URL object returns an empty string for .port when it matches the scheme default, which hides information you often need. This parser fills it in explicitly from a built-in map (http to 80, https to 443, ftp to 21) so you always see which port a request actually targets.
Are URLs with tokens or API keys safe to paste here?
Yes. Parsing runs locally through your browser's native URL constructor with no network requests, so pre-signed links, OAuth callbacks, and internal hostnames stay on your device — Toolk's page analytics never receive what you paste — and any userinfo password is masked in the display.
How can I tell if a value has been percent-encoded twice?
Look at the decoded-value column: this parser wraps decodeURIComponent so malformed escapes fall back to the raw string instead of throwing. If the “decoded” output still shows % sequences like %2520, something upstream encoded twice — fix the producer rather than decoding again. To re-encode single values cleanly afterward, use Toolk's URL encoder (/tools/url-encoder).