URL Encode
& Decode

What is URL Encoding and Why Does It Exist?

URL encoding, formally called percent-encoding, is a mechanism for transmitting data inside a Uniform Resource Identifier (URI) when that data contains characters that would otherwise be misinterpreted by the URI grammar. The standard governing how URLs are constructed, RFC 3986, defines a limited set of characters that are safe to appear unescaped: the letters A through Z, digits 0 through 9, and a handful of punctuation marks like hyphen, underscore, period, and tilde. Anything outside that allowed alphabet, including spaces, accented letters, ideographic characters from Asian scripts, emojis, and most punctuation, must be converted into its percent-encoded form before it can travel through HTTP, be stored in a browser address bar, or be logged by a server.

The mechanic is deliberately simple. Each character that needs encoding is first represented as its byte sequence under UTF-8, and then each byte is rewritten as a percent sign followed by two hexadecimal digits. A literal space becomes %20 because the ASCII value of a space is decimal 32, hex 20. The Japanese character for east, 東, encodes to %E6%9D%B1 because UTF-8 represents it across three bytes. Because percent-encoding operates byte by byte rather than character by character, any binary data, in any encoding, can be safely shipped through a URL as long as the producer and consumer agree on the underlying character set.

The standard predates the modern web by more than a decade. Early specifications for FTP, Gopher, and electronic mail required a way to embed arbitrary text inside short identifiers, and the percent-encoding idea was lifted into RFC 1738 in 1994, then refined in RFC 2396 and finalized in RFC 3986 in 2005. Today it is the bedrock of nearly every web interaction. Every link you click, every form you submit, every API request your phone fires off in the background passes data through this encoding layer. Understanding it well is one of the highest-leverage pieces of knowledge a web developer can have because encoding errors silently corrupt data, break analytics, expose security holes, and produce 404 errors that look identical to genuinely missing resources.

Reserved Characters, Unreserved Characters, and the Gray Zone

RFC 3986 splits the printable ASCII character set into three buckets that determine encoding behavior. The unreserved set contains the 66 characters that may appear in any URL component without ever being escaped: the 26 uppercase letters, the 26 lowercase letters, the 10 digits, and the four marks hyphen, underscore, period, and tilde. These are guaranteed safe and an encoder must not escape them, because percent-encoding an unreserved character produces a URL that is not equivalent under canonical comparison even though most clients treat it the same. Producing %41 instead of A is technically valid but considered incorrect.

The reserved set contains characters that carry structural meaning at certain positions in a URL. Generic delimiters like colon, slash, question mark, hash, square brackets, and at-sign separate top-level components and must be encoded when they appear inside a component as data rather than as a separator. Sub-delimiters such as exclamation point, dollar sign, ampersand, apostrophe, parentheses, asterisk, plus, comma, semicolon, and equals sign have application-specific meaning, most notably in query strings where ampersand separates pairs and equals separates keys from values. A reserved character may be left unescaped if it serves its structural purpose at that position, or it may be encoded to disambiguate.

Everything else, sometimes called the unsafe set, must always be percent-encoded. This bucket includes the space, the angle brackets less than and greater than, the double quote, the curly braces, the vertical bar, the backslash, the caret, the backtick, and all control characters below ASCII 0x20. It also includes every byte above 0x7F, which is where non-Latin scripts and emojis live. The space is particularly tricky because three different conventions exist: %20 in path and query, plus in form data, and %20 in fragments. Encoders aimed at general URLs should output %20 because it is universally accepted, while form-specific encoders use plus.

The tilde character has an unusual history. RFC 1738 listed it as unsafe, but RFC 3986 promoted it to the unreserved set because real-world systems treated it as safe anyway. As a result, older code may still encode tilde to %7E unnecessarily. Both forms are valid and decode identically, so do not be surprised when comparing the output of two encoders that one is more conservative than the other. The same is true for asterisk, parenthesis, and apostrophe, which JavaScript's encodeURIComponent leaves alone but RFC 3986 permits encoding for safety inside contexts like email mailto links where they have additional meaning.

URL Encoding Across Languages and Frameworks

Every popular programming language ships with built-in URL encoding utilities, but the defaults and edge cases vary in ways that matter. In JavaScript, encodeURIComponent is the workhorse for parameter values and leaves the marks hyphen, underscore, period, tilde, exclamation, asterisk, apostrophe, and parenthesis unescaped. In Python, urllib.parse.quote with safe="" produces nearly identical output, but the default safe parameter leaves slash unescaped which is rarely what you want for individual values. PHP exposes both urlencode and rawurlencode, where urlencode follows the form-data convention of plus signs for spaces and rawurlencode follows RFC 3986. Java's URLEncoder is the same form-data variant and requires an explicit UTF-8 charset argument to avoid platform-default encoding pitfalls. Ruby on Rails uses CGI.escape and ERB::Util.url_encode for two slightly different conventions.

Go's net/url package provides both QueryEscape for query parameters and PathEscape for path segments, and the distinction is genuinely useful because path segments allow more characters unescaped than query values do. C# offers HttpUtility.UrlEncode for legacy ASP.NET compatibility and Uri.EscapeDataString for RFC 3986 conformance, with the latter being the correct choice for new code. Rust developers typically reach for the url crate or the percent-encoding crate, both of which expose granular control over which character sets are considered safe in which contexts. The variation across languages means that round-tripping a value from one stack to another can produce subtly different bytes for the same input, which matters when computing cache keys, signing requests cryptographically, or comparing URLs for equality.

A particularly thorny case is signed URL construction for cloud services like AWS S3, Google Cloud Storage, and Azure Blob Storage. These services compute a cryptographic signature over the canonical request, which includes the URL-encoded query string. If the client encodes the parameters with one convention and the server canonicalizes them with another, the signatures will not match and the request is rejected as unauthorized. AWS Signature Version 4 specifies its own canonical encoding rules that differ from RFC 3986 in subtle ways: spaces become %20, plus becomes %2B, asterisk becomes %2A, and unreserved characters per RFC 3986 are left alone. Every official SDK implements these rules correctly, but hand-rolled signers frequently get them wrong. The tool above accepts arbitrary input and shows you exactly what bytes come out, which is invaluable when debugging signature mismatches by comparing your client output against the AWS canonical request string.

Modern URL parsing has converged around the WHATWG URL Standard, which the URL constructor in browsers and the URL class in Node.js both implement. This standard supersedes RFC 3986 with a more permissive and browser-aligned set of rules, including automatic normalization of hosts to lowercase, removal of default ports, and resolution of dot segments in paths. The encoding behavior is mostly compatible but differs in edge cases involving backslashes, leading and trailing whitespace, and ASCII control characters. When writing new code, prefer the URL constructor and the searchParams interface for query manipulation because they implement the standard correctly and handle the round-tripping details automatically. Use this tool when you need to inspect or override what the standard library does behind the scenes.