URL Decode

Article Summary: URL encoding ensures that data passed through URLs is transmitted correctly without ambiguity or corruption, by replacing unsafe and reserved characters with percent-encoded equivalents. This tool encodes plain text to its URL-safe form and decodes percent-encoded strings back to human-readable text, making it essential for debugging query strings, API calls, and web form data.

What Is URL Encoding?

URL encoding, formally known as percent-encoding, is a mechanism defined in RFC 3986 (the URI specification) for encoding arbitrary data within a Uniform Resource Identifier (URI). The basic rule is: any character that is not an unreserved character (letters A-Z, a-z, digits 0-9, and the symbols -, _, ., ~) must be encoded before being included as a data value in a URL.

Encoding works by replacing each unsafe byte with a percent sign followed by the byte's two-digit hexadecimal representation. For example, a space character (ASCII 0x20) becomes %20, a forward slash (ASCII 0x2F) becomes %2F, and a hash symbol (ASCII 0x23) becomes %23. This ensures that structural URL characters retain their special meaning while the same characters appearing as data are safely transmitted without confusion.

URL encoding is fundamental to web development. It is used in query string parameters, form submissions, REST API calls, OAuth tokens, redirect URLs, and virtually every other context where data is embedded in a URL. Failing to encode properly is a common source of bugs, broken links, and security vulnerabilities.

How It Works

Encoding Process

To encode a string, each character is examined. Unreserved characters are passed through unchanged. Every other character — including spaces, punctuation, Unicode characters, and non-ASCII bytes — is converted to its UTF-8 byte representation, and each byte is percent-encoded. For example, the string hello world! encodes to hello%20world%21 because space (0x20) and exclamation mark (0x21) are not unreserved characters.

Decoding Process

Decoding reverses the process: each %XX sequence is identified, the hex value is converted back to a byte, and the byte sequence is interpreted as UTF-8 text. Modern browsers and server frameworks perform this automatically for standard URL components, but developers often need to decode manually when inspecting log files, debugging API calls, or processing raw query strings.

Component-Level vs Full URL Encoding

A critical distinction in URL encoding is that you should never encode an entire URL at once. Encoding the structural characters of a URL (like the :// in https or the / separating path segments) would break the URL entirely. Instead, encoding is applied only to the data portions of a URL — specifically the values in query string parameters and path segments that contain user-supplied or dynamic data.

URL Encoding vs HTML Encoding

URL encoding and HTML encoding (also called HTML entity encoding) are often confused because both deal with escaping special characters, but they serve entirely different purposes and use different syntax.

URL encoding uses percent-encoded sequences (%20, %26, %3D) and applies to data embedded within URIs. It is governed by RFC 3986 and used in HTTP requests, link construction, and API calls.

HTML encoding uses named or numeric entity references (&, <, >,  ) and applies to data embedded within HTML markup. It is governed by the HTML specification and used to prevent cross-site scripting (XSS) attacks and to represent characters that have special meaning in HTML.

When building a web page that includes URLs with dynamic data, you may need both: URL-encode the parameter values first, then HTML-encode the entire URL when placing it in an href attribute. Mixing up the two encoding systems is a common source of subtle bugs in web applications.

When URL Encoding Goes Wrong

The most common URL encoding mistake is double-encoding. This happens when a string that is already percent-encoded is encoded a second time, turning %20 into %2520 (because the % sign itself gets encoded as %25). Double-encoded URLs typically result in broken links, 404 errors, or mangled query string values on the server side.

Another common mistake is inconsistent encoding — encoding some parameters but not others, or encoding structural URL characters that should remain unencoded. This can result in ambiguous URLs that browsers and servers interpret differently, causing hard-to-reproduce bugs.

A third issue arises with the plus sign (+) vs %20 for spaces. In query strings (the part of the URL after ?), spaces are often represented as + rather than %20. This convention comes from the HTML form encoding format (application/x-www-form-urlencoded) and is handled correctly by most server frameworks. However, using + outside of a query string context (e.g., in a URL path) can cause problems, as it may not be decoded as a space by all systems.

Common Use Cases

Debugging API Calls and HTTP Logs

When inspecting raw HTTP request logs or API call traces, query strings appear in their encoded form. A URL parameter like q=hello%20world%21 needs to be decoded to understand what the user actually submitted. This tool lets developers instantly decode encoded log data without writing a script.

Building Query Strings Programmatically

When constructing redirect URLs, OAuth authorization URLs, or API request URLs in code, parameter values must be properly encoded. Checking the encoded output of a value before embedding it in a URL helps catch encoding mistakes early in development.

Decoding Redirect and Callback URLs

OAuth flows, SSO callbacks, and payment gateway redirects often pass encoded URLs as parameters. For example: redirect_uri=https%3A%2F%2Fexample.com%2Fcallback. Decoding these values manually is often necessary during integration debugging.

Technical Reference: Common Percent-Encoded Characters

Frequently Asked Questions

What is URL encoding?

URL encoding is the process of converting characters that are not safe for use in URLs into a percent-encoded format, where each byte of the character is represented as %XX (where XX is the hexadecimal byte value). It is standardized in RFC 3986 and is required for safely embedding arbitrary data — such as user input, search queries, or redirect targets — into URLs without breaking their structure.

Why are spaces encoded as %20 in URLs?

Spaces are not allowed in URLs because they are ambiguous — a space in a URL could indicate the end of the URL or a typographical error. RFC 3986 classifies spaces as "unsafe" characters that must be percent-encoded. The encoding of a space is %20 because the ASCII value of a space character is decimal 32, which is hexadecimal 20. In HTML form query strings, spaces are alternatively encoded as + by convention, but %20 is the correct encoding per the URI standard.

What is the difference between encodeURI and encodeURIComponent?

In JavaScript, encodeURI() encodes a full URL but leaves the structural characters intact (it does not encode :, /, ?, &, #, =, and a few others). encodeURIComponent() is more aggressive — it encodes all characters except unreserved characters, including the structural URL characters. Use encodeURIComponent() for encoding individual query parameter values, and encodeURI() only when encoding a complete URL where the structure must be preserved. Using encodeURI() on a parameter value will leave characters like & and = unencoded, which will corrupt the query string.

What is the difference between + and %20 for spaces?

Both + and %20 represent a space character in URLs, but in different contexts. The + convention comes from the application/x-www-form-urlencoded format used by HTML forms for query strings. %20 is the RFC 3986 percent-encoding for a space and is valid in any URL component including path segments. For query string parameters in modern APIs, both are generally decoded as spaces by server frameworks, but %20 is more universally correct. In URL path segments, only %20 should be used — a literal + in a path is not decoded as a space.

Should I encode the entire URL or just the parameters?

You should never encode an entire URL including its structural characters. Encoding a full URL would convert :, /, ?, &, and other structural characters into percent-encoded form, rendering the URL completely invalid. The correct approach is to encode only the data values within query string parameters and dynamic path segments. The structural parts of the URL (scheme, host, path delimiters, query delimiters) must remain as literal characters for the URL to be parseable.

Conclusion and Takeaways

URL encoding and decoding are foundational skills for web developers, DevOps engineers, and anyone working with APIs, HTTP logs, or web forms. Understanding percent-encoding — when to apply it, which characters require it, and how it differs from HTML encoding and form encoding — prevents a wide class of subtle bugs. Use this tool to quickly encode parameter values before embedding them in URLs, or to decode percent-encoded strings from logs and API traces for human-readable inspection.