URL Encoder & Decoder — Percent-Encode URLs Online

A URL can only contain a specific set of ASCII characters defined in RFC 3986. Characters outside this safe set — including spaces, non-ASCII letters, punctuation marks, and Unicode characters — must be encoded before they can appear in a URL. Percent-encoding replaces each unsafe byte with a percent sign followed by two uppercase hexadecimal digits representing the byte value. For example, a space becomes %20, an exclamation mark becomes %21, and the Japanese character "あ" becomes %E3%81%82 (the three UTF-8 bytes of that character, each percent-encoded). The encoding is based on UTF-8 byte values, so any Unicode character can be represented. Characters that are reserved in URL syntax — such as /, ?, #, =, and & — must also be encoded when they appear inside a value rather than as structural delimiters, to prevent the URL parser from misinterpreting them.

JavaScript provides two built-in functions for URL encoding, and choosing the wrong one is a common mistake. encodeURI is designed for encoding a complete URL. It leaves structural characters like :, /, ?, #, &, and = unencoded because they serve as delimiters in a full URL. encodeURIComponent is designed for encoding a single value that will be placed inside a URL component — a query string value, a path segment, or a fragment. It encodes everything except unreserved characters (letters, digits, -, _, ., ~), including the structural characters that encodeURI skips. This tool uses encodeURIComponent, which is the correct choice when you are encoding a search term, a username, a file name, or any other value that will be embedded into a larger URL. Using encodeURI for a parameter value can cause the URL to be parsed incorrectly if the value contains &, =, or other reserved characters.

The most frequent use of URL encoding is in query strings. When you append user-supplied values to a URL — such as a search term, filter, or user ID — any character in that value that is also a URL delimiter must be encoded. If a user searches for "coffee & tea", the query string must be ?q=coffee%20%26%20tea, not ?q=coffee & tea. The unencoded ampersand would be interpreted as a separator between two parameters, breaking the query. Similarly, a value containing = would break the key-value pair format. Good practice is to always percent-encode every query parameter value when constructing URLs in code. In JavaScript use encodeURIComponent(), in Python use urllib.parse.quote(), and in PHP use rawurlencode() (which uses %20 rather than + for spaces, matching RFC 3986).

File names and path segments in URLs also require encoding when they contain spaces or special characters. A file named "my report 2024.pdf" must be referenced as /files/my%20report%202024.pdf in a URL. Spaces in path segments cause broken links in many HTTP clients and servers. Forward slashes (/) within a path segment must be encoded as %2F to prevent the server from interpreting them as directory separators. This is especially relevant for REST API routes where resource identifiers may contain slashes or other special characters. When building URLs dynamically, always encode each path segment with encodeURIComponent before joining them with literal slashes rather than passing the full path through a single encoding function, which would encode the delimiters as well.

Different programming languages and frameworks have slightly different URL encoding behaviors. JavaScript's encodeURIComponent does not encode the characters !, ', (, ), and *, even though RFC 3986 technically allows encoding them. Python's urllib.parse.quote() encodes those characters by default but can be configured with a safe parameter. PHP's urlencode() encodes spaces as + (the HTML form convention) while rawurlencode() uses %20 (RFC 3986). On the server side, frameworks often decode incoming query strings automatically, but understanding the raw encoding helps diagnose issues when values are double-encoded or partially decoded. When integrating with external APIs, always check whether the API expects application/x-www-form-urlencoded format (which uses + for spaces) or strict RFC 3986 encoding (which uses %20).