Question 1

What is the difference between URL parsing and URL encoding?

Accepted Answer

URL parsing decomposes a complete URL string into named components — protocol, host, path, query, etc. URL encoding (percent-encoding) transforms specific characters within a URL into their hex-escaped form (space → %20, & → %26) so that the URL parses correctly through HTTP. Our URL Parser does the former; our URL Encoder does the latter. They are complementary tools: parsing helps you understand a URL's structure, encoding helps you build one safely.

Question 2

Why does my URL not parse?

Accepted Answer

Three common causes: (1) missing scheme — URLs require a protocol prefix like https:// or mailto:; (2) malformed characters in the host (spaces, unescaped non-ASCII); (3) the input is a partial URL (e.g. /path?query) rather than a complete absolute URL. The WHATWG URL parser is strict by design — it rejects ambiguous inputs to prevent security bugs that historically arose from lenient URL parsers (e.g. the 2019 IDN homograph attack family). If your input is a partial URL, prefix it with a known origin like https://example.com to parse it.

Question 3

What is the difference between host and hostname?

Accepted Answer

hostname is the domain or IP address alone (example.com). host is hostname plus the port when one is explicitly specified (example.com:8080). For a URL like https://example.com/page, hostname and host are identical because the port (443) is implicit. For https://example.com:8080/page, hostname is example.com and host is example.com:8080. The distinction matters when reconstructing a URL or comparing two URLs for "same origin" — origin includes the explicit port.

Question 4

Why are some characters in the URL percent-encoded?

Accepted Answer

Percent-encoding (RFC 3986) escapes characters that are either reserved (have special meaning in URLs, like ? & = #) or unsafe (space, non-ASCII, control characters) by replacing them with %XX where XX is the hex byte value. Space → %20, & → %26, / → %2F. Encoding is required wherever the literal character would be parsed differently — for example, an & inside a query value must be %26 to avoid being parsed as a parameter separator. Our parser shows you BOTH the decoded readable value AND the raw percent-encoded form so you can spot encoding bugs.

Question 5

Are double-encoded values bad?

Accepted Answer

Usually yes. Double-encoding (e.g. %2520 instead of %20) happens when a value is percent-encoded once and then encoded again — typically when a client URL-encodes a value that was already URL-encoded by an upstream system. The server then decodes once, leaving %20 in the result, which is interpreted as the literal three-character string "%20" instead of a space. Spot it by comparing the Raw and Decoded values: if the decoded value still contains percent-encoding patterns, double-encoding happened somewhere. Fix at the source.

Question 6

Why is the userinfo (user:password) field deprecated?

Accepted Answer

Embedding credentials in URLs (https://user:pass@host/) was originally intended for FTP and similar protocols. For HTTP, the Authorization header is the modern, safer mechanism — it does not appear in browser history, server access logs, or HTTP Referer headers. RFC 9110 §11 deprecates the user:password URL form for HTTP. Some legacy systems (especially database connection strings like postgres://user:pass@host/db) still use the form because the connection is direct rather than over a request/response protocol. Our parser shows userinfo when present, but masks the password field for safety.

Question 7

How do I extract a single query parameter?

Accepted Answer

Look at the Query parameters table — each row shows one key-value pair. If a parameter appears multiple times in the URL (e.g. ?tag=red&tag=blue), each occurrence appears as a separate row. To extract programmatically, use the native URLSearchParams API: const params = new URL(url).searchParams; params.get("utm_source") returns the first value; params.getAll("tag") returns an array of all values. Modern frameworks (Next.js searchParams, Express req.query) wrap this API but the underlying parser is identical.

Question 8

Does this work for URLs containing tokens or secrets?

Accepted Answer

Yes — and your data stays private. URLs frequently contain auth tokens (Bearer tokens in query strings, S3 pre-signed URLs, OAuth callback URLs), API keys, customer identifiers, and internal hostnames. All parsing happens in JavaScript inside your browser tab. No fetch, no XHR, no analytics event with URL data. The same privacy guarantee applies to all our developer tools — we treat URLs with the same care as financial or PII inputs.

Question 9

What is the fragment (#hash) for?

Accepted Answer

The fragment is a client-side-only identifier — typically an anchor target (#section-2) or a single-page-application route (#/dashboard). Critically, the fragment is NEVER sent to the server in HTTP requests; only the browser sees it. This makes fragments useful for: (1) deep links to scroll positions within long pages; (2) sensitive client-state values you do not want logged in server access logs (some OAuth implicit flows use fragments for this reason); (3) SPA routing in older single-page apps. Modern SPAs prefer the History API and avoid fragments for routing.

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	email	email
3	ref	top	top

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.

Free URL Parser: Decompose Any URL into Protocol, Host, Path & Query Parameters

WHATWG URL Standard

Query Parameters as Table

Path Segments + Defaults

100% Client-Side

Every Component of Every URL, In One Glance

The Seven URL Components (WHATWG URL Standard)

Six Daily Uses of a URL Parser

Four URL Bugs This Parser Helps You Catch

Related Developer Utilities