What Does URL Encoding Actually Do

October 17, 2026 • NOFYI Editorial Team

What Is URL Encoding?

URL encoding is the process of converting characters in a web address into a safe form that can travel across the internet without being misinterpreted. A URL, or Uniform Resource Locator, has a strict structure. Certain characters have special jobs inside a URL. For example, the question mark starts the query string, the ampersand separates parameters, the equals sign assigns a value, the slash separates path segments, and the hash sign starts a fragment. Other characters, such as spaces, are not allowed at all in a URL. URL encoding solves this by replacing a character that cannot be used directly with a percent sign followed by two hexadecimal digits that represent its code. That is why it is also called percent-encoding.

A simple example makes the idea clear. A space becomes %20. An ampersand becomes %26. A question mark becomes %3F. So the phrase hello world and friends? becomes, when encoded as a single value, hello%20world%20%26%20friends%3F. The encoded version looks less friendly to a human reader, but to a browser or server it is unambiguous. The server knows that %20 means a space that is part of the data, not a separator, and that %26 means an ampersand that is part of the data, not the start of a new parameter. Without encoding, the same string would be split in the wrong places and the meaning would be lost.

URL encoding is not encryption. It does not hide information or make it secure. Anyone can decode an encoded URL just as easily as you can encode one. Its purpose is to preserve meaning while moving data through a system that reserves some characters for structure. Think of it as punctuation for machines: the percent sign tells the receiver, treat the next two characters as a code for a single character, not as literal text.

Why URLs Need Encoding

The web was built on standards that define which characters may appear directly in a URL and which must be encoded. Unreserved characters such as letters, digits, hyphens, underscores, periods, and tildes can appear as they are. Reserved characters such as colon, slash, question mark, hash, brackets, at sign, exclamation mark, dollar sign, ampersand, apostrophe, parentheses, asterisk, plus sign, comma, semicolon, and equals sign have structural roles. They can appear in the places where their structural role applies, but when they appear inside data, they must be encoded. Other characters, including spaces, non-ASCII letters, and control characters, are not allowed directly and must always be encoded.

This distinction matters because a URL is not just a label. It is an instruction. A browser splits a URL into scheme, host, path, query, and fragment. A server then splits the query into keys and values. If a value contains an unencoded ampersand, the server will treat it as a separator and split one value into two parameters. If a value contains an unencoded question mark, it can confuse the boundary between path and query. If a value contains a space, the URL may be truncated, broken by a link parser, or rejected outright. Encoding removes that ambiguity by making it clear which characters are structure and which are data.

Encoding also matters for characters beyond English. Letters with accents, characters from non-Latin scripts, and emoji all need encoding before they can appear in a URL. In practice, browsers often display these characters in a readable form in the address bar while sending the encoded form behind the scenes. The readable display is a convenience. The encoded form is what actually travels over the network and what the server receives.

How to Encode a URL Value

Encoding a single value is straightforward once you know which part of the URL you are working with. The general method is to encode the data, not the whole URL. That distinction is the single most important rule in this guide, and most encoding mistakes come from ignoring it.

Step 1: Identify the Piece That Is Data

Look at the URL and find the part that is user input or variable data. That might be a search term, a name, a message, or a filter value. That piece is the part that needs encoding. The structural parts, such as https://, the domain, the slashes between path segments, the question mark before the query, and the ampersands between parameters, should stay as they are.

Step 2: Encode the Data Value

Pass the data value through an encoder. In a browser, you can use the built-in function encodeURIComponent in JavaScript. In Python, you can use urllib.parse.quote. In many online tools, you can paste the value into an encoder field. The encoder will replace spaces with %20, ampersands with %26, question marks with %3F, equals signs with %3D, and so on. Letters and digits are left unchanged.

Step 3: Place the Encoded Value Back Into the URL

Insert the encoded value into the URL structure. For example, if the base URL is https://example.com/search?q= and the search term is hello world, the final URL becomes https://example.com/search?q=hello%20world. The question mark and equals sign remain unencoded because they are structure. Only the search term is encoded.

Step 4: Test the Link

Open the resulting URL, check that the page loads, and confirm that the server received the value you intended. If a search for hello world returns results for hello only, or if a name with an ampersand gets cut off, encoding was probably missing or applied to the wrong part. A quick test catches most of these errors.

Worked Example: Encoding a Phrase With a Space, Ampersand, and Question Mark

Let us work through the example from the title in full. The original phrase is: hello world and friends? Written out, it contains a space between hello and world, a space, an ampersand, a space, the word friends, and a question mark at the end. If you tried to place that phrase directly into a query parameter without encoding, the result would be broken. The ampersand would look like a parameter separator, and the question mark would look like the start of another query string. The server would not receive the phrase you meant to send.

Encoding the phrase character by character gives: hello%20world%20%26%20friends%3F. Here is the mapping. The space between hello and world becomes %20. The space after world becomes %20. The ampersand becomes %26. The space after the ampersand becomes %20. The letters in hello, world, and friends stay unchanged. The question mark becomes %3F. The encoded string is longer, but every character now has one clear meaning.

Now place that encoded value into a URL. Suppose the base is https://example.com/search?message=. The full URL becomes https://example.com/search?message=hello%20world%20%26%20friends%3F. When the server decodes the message parameter, it recovers exactly hello world and friends? The ampersand and question mark are restored as data, not treated as structure. That round trip, encode before sending and decode after receiving, is the whole point of URL encoding.

Notice what was not encoded. The https://, the domain, the slash, the question mark that starts the query, and the equals sign that assigns the message value were all left alone. If you had encoded the entire URL, those structural characters would have become %3A, %2F, %3F, and %3D, and the result would no longer be a valid clickable link. Encoding the whole URL is one of the most common mistakes, and this example shows why it fails.

When to Encode and When Not To

Encode data values before you place them in a URL. Encode form values, search terms, names, messages, file names, and any other variable content that might contain spaces or special characters. Encode query parameter names and values, and encode path segments that come from user input. Most modern web frameworks and HTTP libraries encode values for you when you use their parameter-building helpers, so you often do not need to encode by hand. Using those helpers is usually safer than building URLs with string concatenation.

Do not encode a complete URL. Do not encode structural characters that are doing their proper job. Do not encode a value twice. Double encoding is a common bug. It happens when a value is encoded once, and then encoded again, so that the percent sign itself becomes %25. For example, a space encoded once becomes %20. Encoded a second time, the percent sign in %20 becomes %25, giving %2520. When the server decodes once, it gets %20, not a space. The user then sees a literal %20 in the output instead of a space. If you see %25 in a URL, double encoding is a likely cause. The fix is to encode once, at the point where the value enters the URL, and to avoid passing an already-encoded value through another encoder.

Also be careful with plus signs. In the query part of a URL, some systems treat a plus sign as a space when decoding form data. That convention comes from HTML form submission. In other contexts, a plus sign means a literal plus. To avoid confusion, encode a literal plus sign as %2B when it is part of data. Relying on the plus-as-space convention is fragile, and explicit percent-encoding is clearer.

Common Encoding Mistakes

The first mistake is not encoding at all. A link built by joining a base URL and raw user input will break as soon as the input contains a space, ampersand, question mark, hash, or equals sign. The second mistake is encoding the whole URL, which breaks the structure. The third is double encoding, which leaves %25 sequences in the output. The fourth is mixing encoding for different parts of the URL. Path segments and query values have slightly different rules in some systems, so using the wrong encoder for the wrong part can produce different results. The fifth is assuming that encoding makes data safe from security attacks. It does not. Encoding is about structure, not security. Input still needs validation and proper handling on the server.

Limitations of URL Encoding

URL encoding preserves structure, but it does not compress data, hide it, or guarantee that the server will interpret it the way you expect. Different servers and frameworks can differ in how they decode certain characters, especially plus signs and non-ASCII characters. Encoding also makes URLs longer and harder for people to read. A long encoded URL is difficult to copy, check, or debug by eye. For those reasons, it is better to keep URLs short and simple when you can, and to reserve encoding for the values that genuinely need it.

Encoding also does not fix a poorly designed URL. If a value contains a large amount of text, placing it in a URL is often the wrong choice. A POST request body, a stored identifier, or a shorter reference is usually better. URLs have practical length limits in browsers, servers, and proxies, and very long URLs can be truncated or rejected. Encoding makes a long value even longer, because each special character becomes three characters. Keep that trade-off in mind when you design links and forms.

Finally, encoding does not protect against phishing or misleading links. An encoded URL can still point to a malicious site, and the encoded form can make it harder for a person to tell where the link goes. Always check the domain of a link before clicking, especially if the path or query looks heavily encoded. The domain is the part that tells you who operates the site.

Frequently Asked Questions

What does %20 mean in a URL?

%20 is the encoded form of a space. The percent sign introduces a two-digit hexadecimal code, and 20 is the code for a space. When a server decodes the URL, it turns %20 back into a space in the data value.

What does %26 mean in a URL?

%26 is the encoded form of an ampersand. It tells the server that the ampersand is part of the data, not a separator between parameters. Without encoding, an ampersand in a value would split the value into two parameters.

Should I encode an entire URL?

No. Encode only the data values that go inside a URL. Keep the structural characters, such as the scheme, slashes, question mark, equals sign, and parameter separators, unencoded. Encoding the whole URL breaks it.

Why do I see %25 in my URL?

%25 is the encoded form of a percent sign. Seeing it usually means the value was encoded twice. The fix is to encode once, at the point where the value enters the URL, and to avoid passing an already-encoded value through another encoder.

Conclusion

URL encoding replaces characters that have special meaning, or that are not allowed, with a percent sign and a two-digit code. A space becomes %20, an ampersand becomes %26, and a question mark becomes %3F. The worked example shows the pattern: hello world and friends? becomes hello%20world%20%26%20friends%3F when encoded as a single value. The rule to remember is simple. Encode the data, not the whole URL. Encode once, test the link, and keep URLs as short and clear as you can. With that approach, your links will carry exactly the values you intended, without being split, truncated, or misread along the way.