URL Encode and Decode: What It Is and When You Need It

URLs can only contain a specific set of characters. Letters, numbers and a handful of symbols like hyphens, underscores and periods are safe in URLs. Characters outside this set, including spaces, special characters, non-Latin letters, and symbols with special meaning in URL syntax, must be encoded before they can be included in a URL without causing problems. URL encoding replaces unsafe characters with a percent sign followed by the two-digit hexadecimal code for that character.

A space becomes %20 in URL encoding. An ampersand becomes %26. A French é becomes %C3%A9 because its Unicode representation requires two bytes in UTF-8 encoding. The process is systematic and reversible, which is why decoding is equally straightforward.

Why URL encoding exists

URLs were designed when the internet was primarily English-language and technical. The original specification reserved certain characters for specific purposes within URL syntax. The question mark separates the path from the query string. The ampersand separates query parameters. The hash marks the start of a fragment. The colon and slashes define the protocol and server components. Any character that has a reserved meaning in URL syntax must be encoded when it appears as data rather than as a structural element.

Consider a search query for the phrase fish and chips. If the URL passes this as a parameter without encoding, it becomes search?q=fish and chips. The space in the middle breaks the URL in most parsers. The encoded version is search?q=fish%20and%20chips, which unambiguously represents the three-word phrase as a single parameter value. Any URL parser that processes this correctly extracts fish and chips as the search term.

Internationalization extended the need for encoding further. Unicode characters that represent non-Latin scripts, accented letters and symbols outside the original ASCII set all require encoding in URLs. This is why URLs from Arabic, Chinese, Japanese and other non-Latin-script websites often appear as long sequences of percent-encoded characters when copied from the browser address bar, even though the browser displays them in human-readable form.

URL encoding versus HTML encoding

URL encoding and HTML encoding are different systems that are easy to confuse because they both exist to make characters safe in specific contexts. URL encoding uses percent signs and hexadecimal codes. HTML encoding uses named entities or numeric references. An ampersand in HTML is written as & or &. The same ampersand in a URL is written as %26.

The context determines which encoding to use. Data that will appear in a URL needs URL encoding. Content that will appear in HTML markup needs HTML encoding. Data in a URL that is embedded in HTML may need both applied in the correct order. Getting the encoding context wrong produces broken links or display errors that can be difficult to trace without understanding why the two encoding systems exist.

When you need to decode a URL

Reading a URL that contains encoded characters is the most common reason to decode. A URL shared from a search engine or a web application often contains encoded query parameters that are meaningful if read but incomprehensible as encoded strings. Decoding reveals the actual search terms, filter values or parameters that the URL encodes.

Debugging web applications frequently requires decoding URL parameters to verify that data is being passed correctly. An API call that is not working as expected may have an encoding error in one of its parameters. Decoding the full URL and examining each parameter value in readable form is often the fastest way to identify what is wrong.

Extracting data from server logs is another common use. Web server logs record the full URL of each request including encoded parameters. Analyzing log data to understand what users searched for, what products they viewed, or what errors occurred requires decoding the logged URLs to make them readable.

Common encoding mistakes

Double encoding happens when a value that is already encoded gets encoded again. The encoded %20 for a space contains a percent sign, and if the whole string is encoded again, the percent sign itself becomes %25, turning %20 into %2520. The result is a URL that, when decoded once, still contains an encoded value rather than the original text. This is a common source of bugs in web applications that process URL parameters through multiple functions.

Forgetting to encode special characters in query parameter values causes problems when those characters have meaning in URL syntax. An API key that contains an equals sign or a plus sign, a product name that contains an ampersand, or a user-submitted search term that contains special characters all need to be encoded before being included in a URL parameter.

Encoding characters that should not be encoded can also cause problems. The slash in a URL path segment has a specific meaning, and encoding it as %2F in some server configurations produces a different result than leaving it as a literal slash. Encoding only the data portions of a URL and leaving the structural characters unencoded is the correct approach.

Open the URL Encode/Decode tool below.
Paste the text or URL you want to encode or decode.
Select whether to encode or decode.
Copy the result.

💡 If you are building URLs programmatically, always encode query parameter values individually rather than encoding the entire URL string. Encoding the whole URL encodes the structural characters that should remain literal.

Encode or decode URLs and query strings instantly.

Percent encoding in practice

When building forms that submit data through a GET request, the form values appear in the URL as query parameters. A form field named search with the value blue shoes submits as ?search=blue+shoes or ?search=blue%20shoes depending on the encoding convention used. Either format is decoded correctly by most servers, but they represent different encoding approaches that can produce inconsistencies if mixed.

Plus signs and %20 both represent spaces in URL query strings, but only in the query string portion of a URL. In the path portion, a space must be encoded as %20 because a plus sign in a URL path is a literal plus sign rather than an encoded space. This difference is a common source of bugs in web applications that process URL components without correctly distinguishing between the path and query string portions.

Base64 encoding versus URL encoding

Base64 encoding is sometimes confused with URL encoding because both are used to make data safe in text contexts. They are different systems for different purposes. Base64 converts binary data to a text string using 64 safe characters. URL encoding converts a string with unsafe URL characters to a version that contains only URL-safe characters. Base64-encoded data often needs URL encoding applied on top of it because the Base64 character set includes plus, slash and equals signs, all of which have special meaning in URL context.

Many API systems use Base64 to encode authentication credentials and then require the encoded string to be included in a URL or header. If the Base64 string contains characters with special URL meaning and those characters are not further encoded, the API request may fail or be interpreted incorrectly. Understanding which encoding applies at each layer of the system helps diagnose this class of integration issue.

JSON data passed as a URL parameter needs URL encoding applied to the entire JSON string. The curly braces, colons, commas and quotation marks in JSON all require encoding before the string can safely appear in a URL. A JSON object like {key: value} becomes %7B%22key%22%3A%22value%22%7D when URL encoded, which looks intimidating but decodes cleanly at the receiving end.

Encoding in REST APIs

REST API endpoints receive query parameters in URL-encoded form and body data in formats like JSON or form-encoded pairs. The encoding of the body depends on the Content-Type header. A body with Content-Type application/x-www-form-urlencoded uses URL encoding for key-value pairs. A body with Content-Type application/json contains JSON that should not be URL-encoded, though the JSON values within it may need JSON string escaping for special characters.

API documentation typically specifies whether parameters should be URL-encoded and in which component of the request they should appear. Following the specification exactly prevents subtle encoding bugs where a value that works in testing fails in edge cases involving special characters. Testing API requests with inputs that contain spaces, special characters and non-ASCII text exercises the encoding paths that are most likely to reveal implementation issues.