URL Encoder/Decoder

URL structure — the anatomy of a web address

A URL (Uniform Resource Locator) has a defined structure: scheme://authority/path?query#fragment. Understanding each component clarifies when and how encoding applies.

Scheme (https, http, ftp): followed by ://. Never percent-encoded.

Authority: host name (domain.com) plus optional port (:8080). Domain labels follow DNS rules — only letters, digits, and hyphens; no encoding needed for standard domains. Internationalized Domain Names (IDN) use Punycode encoding (xn-- prefix) rather than percent-encoding.

Path (/products/my item): path segments are separated by /. Characters within a segment that are not "unreserved" (letters, digits, -, _, ., ~) must be percent-encoded. Spaces become %20 (not +, which is only for query strings in application/x-www-form-urlencoded).

Query string (?key=value&key2=value2): uses key=value pairs separated by &. The = and & are structural and must not be encoded as part of the URL structure. But the key and value contents must have their special characters encoded — which is why encodeURIComponent is the right function for query values (it encodes &, =, ?, and /).

Fragment (#section): the part after # is the fragment identifier. It is processed by the browser, not the server. It is never sent in HTTP requests.

When URL encoding goes wrong — common debugging scenarios

URL encoding bugs are common in web development and often subtle. Several patterns appear repeatedly.

Double-encoding: a value that was already encoded is encoded again. %20 (space) becomes %2520 (% is encoded to %25, producing %2520). The browser then decodes once, arriving at %20 instead of a space. Double-encoding happens when a library or framework encodes a string that was already manually encoded. Use a single encoding step at the final output point.

Wrong encoding function: using encodeURI instead of encodeURIComponent for query parameter values. encodeURI doesn't encode &, = or ?, so a URL parameter value containing these characters breaks the query string structure. Always use encodeURIComponent for individual parameter keys and values.

Plus vs %20: HTML forms using application/x-www-form-urlencoded encode spaces as +. Some server frameworks (PHP $_GET, some Python Flask versions, Java Servlet API) decode + back to space. Pure RFC 3986 percent-encoding uses %20. Mixing the two in the same API causes + to be treated as a literal + by RFC 3986-compliant parsers. Standardize on %20 in APIs; use + only in form submissions.

Non-UTF-8 encoding: legacy systems sometimes encode non-ASCII characters in Windows-1252 or Latin-1 encoding rather than UTF-8. %E9 in Latin-1 is é; in UTF-8, é is encoded as %C3%A9. Always specify and use UTF-8.

Building safe URLs — best practices for developers

Building URLs programmatically requires careful encoding to prevent broken links and security vulnerabilities.

Always use the URL API for URL construction in JavaScript: const url = new URL('/search', 'https://example.com'); url.searchParams.set('q', userQuery); url.searchParams.set('page', '2'); // Outputs: https://example.com/search?q=[encoded]&page=2. The URL and URLSearchParams APIs handle encoding automatically and correctly.

Never build query strings through string concatenation: '/search?q=' + userInput + '&page=2'. If userInput contains &, =, or ?, the query string structure breaks. If it contains a #, the remainder becomes a fragment. Use URLSearchParams.set() or your language's equivalent URL-building utility.

For path segments containing user data (like usernames, slugs, or IDs in URLs like /users/username), use encodeURIComponent to encode the segment value before inserting it: '/users/' + encodeURIComponent(username). If the username contains a slash, this prevents it from being interpreted as a path separator.

Open redirect prevention: when redirecting to a URL provided by a user or query parameter, validate that the destination is within your own domain before redirecting. An unvalidated redirect to a URL-encoded external site (https://yoursite.com/redirect?to=https%3A%2F%2Fevil.com) is a common phishing vector.