What URLs Are Made Of

URI, URL, and URN

URI (Uniform Resource Identifier) is the umbrella term. A URL (Uniform Resource Locator) describes how to access a resource—https://example.com/page is a URL. A URN names a resource without location (urn:isbn:978-…). In daily web development, “URL” and “URI” are often used interchangeably for http(s) addresses, but specs distinguish name vs locator. APIs and logs should store canonical URLs with consistent encoding.

Annotated example

Scheme and default ports

Omitting the port means “use the default for this scheme.” Explicit :8080 overrides when dev servers listen off-standard.

Path, query, and parsing traps

Path segments are delimited by /. Trailing slashes can matter to caches and static hosts—pick one canonical form. Query strings start at ? and use & between pairs; keys and values are separated by =. Empty ?key= sends key with empty value; bare ?key may be treated differently by frameworks. Repeated keys (?tag=a&tag=b) are valid; server code must decide whether to take first, last, or collect all.

Relative URLs resolve against a base (RFC 3986). A link href="guides/foo" on https://example.com/docs/ resolves to https://example.com/docs/guides/foo—bugs appear when bases are wrong in emails or SPAs.

Percent-encoding (URL encoding)

Reserved characters—space, &, =, ?, #, +, /, and others—have syntactic roles. When they appear inside data (search terms, file names), encode them as % followed by two hex digits. Space is often encoded as %20; + in query strings historically meant space in application/x-www-form-urlencoded bodies—do not assume + and %20 are interchangeable in every layer.

const q = "rock & roll";
encodeURIComponent(q); // "rock%20%26%20roll"
// Use encodeURIComponent for query VALUES;
// encodeURI for full URLs without breaking structure.

Internationalized domain names and paths

Unicode hostnames appear as punycode (xn--…) in DNS. Paths may contain UTF-8 percent-encoded Unicode when servers and frameworks allow IRIs. Normalization and homograph attacks (cyrillic “a” vs latin “a”) are security concerns—browsers apply same-origin rules on punycode forms.

Origin and same-site rules

The origin combines scheme, host, and port. Cookies, CORS, and fetch policies key off origin—not merely path prefix. A page at https://app.example.com/settings and an API at https://api.example.com are different origins even on the same registrable domain; subdomain takeovers break assumptions if DNS is neglected.

Security considerations

URLs are both navigation and attack surface. Because they appear in address bars, emails, analytics, and server logs, small parsing differences between your framework, a CDN, and a mobile WebView become authorization bugs. Treat every redirect target, callback URL, and webhook endpoint as untrusted input until you have parsed it with a spec-aware API and compared origin, path, and encoded form to an allowlist.

• Open redirects: validate next= parameters against an allowlist of paths or hosts.
• JavaScript URLs: javascript:… in href can execute script; block in user-generated links.
• Mixed content: https pages loading http subresources weaken TLS guarantees.
• Sensitive data in query strings: URLs land in logs, Referer headers, and browser history—prefer POST bodies or headers for tokens.
• Overlong encoding: %252F double-encoding bypasses naive filters—normalize before authorization checks.
• Userinfo phishing: https://evil.com@trusted.com/ may look like trusted.com in UI—modern browsers de-emphasize userinfo.
• Trailing-dot hostnames: example.com. can resolve differently than example.com in some resolvers—normalize before allowlists.
• Backslash vs slash: https://example.com\@evil.com/ tricks parsers that treat \ as / before validation.
• Scheme smuggling: javascript: or data: URLs in href if your sanitizer only checks for http—block non-navigable schemes in user content.

Common mistakes in app code

• Building query strings with string templates instead of URLSearchParams—ampersands in values split parameters silently.
• Using decodeURIComponent on the full href before checking the host—can hide homoglyphs or double-encoded traversal.
• Caching on the full URL string including tracking query order—cache misses and log PII when ids shuffle.
• Assuming Referer omits paths: strict-origin-when-cross-origin still leaks origin; secrets belong in headers or POST bodies.

SSRF and internal hosts

Server-side code that fetches a user-supplied URL (preview cards, importers, webhooks) can be tricked into calling http://127.0.0.1, metadata endpoints, or private RFC 1918 addresses. Block link-local and loopback hosts after parsing; do not rely on string contains checks for localhost. Same-origin policy protects browsers; servers have no such default.

Relative resolution in apps

Single-page applications and email templates often ship relative links. RFC 3986 resolution merges a relative reference against a base URL: ../api/v1/users from https://example.com/app/dashboard/ becomes https://example.com/app/api/v1/users when segments are normalized. Wrong base tags in HTML or incorrect router basename settings produce 404s that look like server bugs but are client-side URL algebra mistakes.

const base = "https://example.com/app/page";
const rel = "../api/items?q=1";
console.log(new URL(rel, base).href);
// "https://example.com/app/api/items?q=1"

Tools and specs align

SmartKitio’s url-encoder and url-decoder run in the browser so you can percent-encode search terms, nested next= URLs, and non-ASCII path segments without guessing which characters are reserved. When a malformed link returns 404 or 400, http-status-lookup explains what the code means while you split the URL with new URL()—scheme, host, path, and searchParams should be inspected separately, not as one opaque string.