URL Encoder and Decoder Guide: Percent-Encoding Explained

Why URLs need encoding

A URL, or web address, is written in a restricted alphabet. Letters, digits and a handful of punctuation marks, such as the hyphen, underscore, dot and tilde, can appear directly. Many other characters cannot, either because they have a special job in the URL, such as the question mark that starts a query string, the ampersand that separates query parameters, and the slash that separates path segments, or because they are not part of the basic ASCII character set, such as accented letters and characters from non-Latin scripts. Percent-encoding is the mechanism that lets such characters travel safely inside a URL.

Percent-encoding replaces a character with a percent sign followed by two hexadecimal digits giving the character's byte value. A space becomes %20, because twenty in hexadecimal is thirty-two in decimal, which is the ASCII code for a space. An ampersand becomes %26, because twenty-six in hexadecimal is thirty-eight, the ASCII code for the ampersand. A URL Encoder & Decoder performs this translation in both directions, and understanding the translation is what lets you read an encoded URL and diagnose a broken link.

Non-ASCII characters are first converted to their UTF-8 bytes, and each byte is then percent-encoded separately. A single accented character therefore becomes two percent-encoded groups, and a character from a script such as Chinese or Arabic becomes three or four. The encoded URL looks long and unreadable, but it is a faithful representation of the original text, and decoding reverses it exactly, provided the encoding was done with UTF-8, which is now the universal standard for the web.

Which characters get encoded

Reserved characters have special meaning and must be encoded when they appear as data rather than as structure. The ampersand separates query parameters, so an ampersand inside a search term must be encoded as %26, or the server will split the term into two parameters at that point. The equals sign separates a parameter name from its value, so an equals sign inside a value must be encoded as %3D. The question mark, slash, hash and plus sign have similar dual roles, and each must be encoded when used as data.

Unreserved characters, letters, digits, hyphen, underscore, dot and tilde, are never encoded, and encoding them is harmless but unnecessary and makes URLs harder to read. A space is the most commonly encoded character in practice, because spaces appear in file names, search terms and titles, and a URL containing a literal space is invalid and will be mangled by many systems. Some systems represent a space in a query string as a plus sign instead of %20, which is a separate convention for form data, and the two should not be confused: in a path segment, a plus sign means a literal plus, while in a query string encoded as form data, it means a space.

The distinction between encoding a whole URL and encoding a single value is important. Encoding a whole URL would also encode its slashes, colons and question marks, destroying its structure. The correct practice is to encode each value separately and then assemble the URL from its structural characters and its encoded values. A tool that offers both whole-URL and component encoding modes should be used in component mode for values, and whole-URL mode only for display or for repairing a URL that is already malformed.

A worked example

Consider a search term consisting of the words hello world, an ampersand, and the word friends, written as hello world and friends with spaces around the ampersand. Encoding it character by character: the letters stay unchanged, each space becomes %20, and the ampersand becomes %26. The encoded result is hello%20world%20%26%20friends. That string can now appear safely as a query value, because it contains no literal space that would break the URL and no literal ampersand that would split the parameter.

Decoding reverses the process. Reading hello%20world%20%26%20friends, each %20 becomes a space and %26 becomes an ampersand, restoring hello world and friends. A useful check is that decoding the encoded result must return the original exactly, and encoding the decoded result must return the encoded string exactly. If either round trip fails, the string was encoded twice, encoded with the wrong character set, or partially encoded by hand, and the failure points to the step that needs fixing.

Double encoding is the most instructive failure. If the encoded string hello%20world is encoded again, the percent sign itself is encoded as %25, giving hello%2520world. Decoding once gives hello%20world, not the original, and a server that decodes once will search for a term containing a literal percent-two-zero rather than a space. Double encoding arises when a value passes through two encoding steps, such as a form that encodes and a script that encodes again, and the cure is to encode exactly once, at the point where the value enters the URL.

The first mistake is encoding the structure. A URL such as https://example.com/search?q=hello%20world has structural characters, the colon, slashes and question mark, that must stay literal, and a value, hello world, that must be encoded. Encoding the whole string produces a useless result in which the structure is destroyed. The second mistake is the opposite: leaving special characters unencoded in values, so that an ampersand in a product name splits a query string and the server receives a truncated or extra parameter.

The third mistake is mixing the plus-sign and percent-twenty conventions for spaces. A path segment containing a plus sign refers to a file name with a literal plus, while a query value containing a plus may be read as a space by form-decoding systems. When a file name contains a plus or a space, percent-encoding it explicitly as %2B or %20 removes the ambiguity. The fourth mistake is assuming that encoding makes a URL safe to paste anywhere: some messaging and document systems still break long encoded URLs at line boundaries, and a link shortener or a proper hyperlink is more reliable than a pasted address for sharing.

Encoding is not encryption and not security. An encoded password, token or personal detail in a URL is still readable by anyone who decodes it, and URLs are stored in browser history, server logs and referrer headers, so sensitive values should never be placed in a URL at all, encoded or not. Encoding protects the structure of the address; it does not protect the contents from readers.

Reading encoded URLs in the wild

The ability to decode by eye is a practical security skill. A link whose visible text promises one destination but whose encoded query contains a different domain, a redirect parameter, or a long string of encoded characters deserves suspicion, and decoding the query often reveals the true destination before clicking. Phishing links frequently hide behind encoding and redirection, and a decoder turns an opaque string into readable evidence.

Related tools cover the neighbouring text and data work. The guide to Base64 UTF-8 Encoding explains a different encoding used for data rather than addresses, the guide to Base64 Decode Errors covers diagnosing encoding failures generally, and the Text Case Converter helps normalise text before it is encoded. Percent-encoding is a small mechanism, but it is the mechanism that lets the web's addresses carry the world's languages and punctuation without breaking, and reading it fluently is a basic literacy for anyone who builds or shares links.

For the surrounding web work, the QR Code Generator turns a finished link into a scannable code, and the Password Generator creates strong credentials for the accounts those links lead to.