URL Encoding Explained: What %20 Means and When Developers Need It
Learn what URL encoding is, why spaces become %20, when to encode and decode URLs, and how to do it instantly with a free online tool.
What URL encoding is and why it exists
URLs can only contain a limited set of safe characters — letters, digits, hyphens, underscores, periods, and tildes. Every other character, including spaces, ampersands, equal signs, slashes used as data rather than path separators, and non-ASCII characters like accented letters or Khmer script, must be encoded before it can appear safely in a URL. URL encoding — also called percent-encoding — replaces each unsafe character with a percent sign followed by the two-digit hexadecimal code for that character's value in the UTF-8 encoding. A space becomes %20 because 32 in decimal is 20 in hexadecimal, and 32 is the ASCII code for a space character. An ampersand becomes %26 because 38 in decimal is 26 in hexadecimal. This encoding ensures that the URL remains unambiguous: a literal ampersand in a query string value is encoded as %26 so it cannot be mistaken for the separator between two query parameters, which is the literal unencoded ampersand character.
When developers encounter URL encoding in practice
URL encoding appears in several common developer scenarios. Query string parameters passed to APIs must be encoded so that special characters in user-supplied values do not break the URL structure. When a user types a search query containing spaces and punctuation, the browser encodes it before sending the HTTP request — which is why browser address bars show %20 or plus signs in place of spaces when you inspect a search URL. File upload APIs that accept file names in request parameters need file names URL-encoded because a file name like "Q1 Report & Analysis.pdf" contains characters that would break a raw query string. Redirect URLs that carry a return-to parameter must be encoded because the target URL itself contains all the characters that are unsafe in a URL. When building these parameters in code, most languages provide built-in functions — encodeURIComponent in JavaScript, urllib.parse.quote in Python, URLEncoder.encode in Java — so that developers do not have to implement the encoding table manually.
The difference between encoding a full URL and encoding a parameter value
This distinction trips up developers who are new to URL encoding. Encoding a full URL is something you almost never want to do, because it would encode the slashes, colons, and question marks that give the URL its structure, producing a meaningless string. What you almost always want to encode is only the data values that go inside query parameters or path segments. In JavaScript, encodeURI encodes a full URL while leaving structural characters intact; encodeURIComponent encodes everything including structural characters and is designed for encoding individual parameter values. If you encode a query parameter value with encodeURI instead of encodeURIComponent, characters like ampersand and equals sign inside the value will not be encoded, which breaks the query string. This is one of the most common URL-handling bugs in frontend JavaScript, and understanding the distinction between encoding a complete URL structure versus encoding a data value that goes inside that structure prevents it entirely.
Decoding URL-encoded strings for debugging and data extraction
URL decoding is the reverse operation: it reads a percent-encoded string and converts each %XX sequence back to its original character. Developers need to decode URLs when inspecting incoming request parameters in server logs, when reading redirect targets that carry encoded return URLs, when extracting search queries from analytics data, or when debugging an API where a client sent malformed or incorrectly encoded parameters. A URL decoder tool lets you paste any encoded string and immediately see the human-readable original, which is far faster than mentally translating hex codes by hand. When the encoded string contains non-ASCII characters — Khmer script, Arabic, Chinese, or accented European characters — decoding is essential because the percent-encoded form is completely unreadable at a glance, while the decoded form shows the original text in its native script.
A practical workflow is to keep the original payload or query nearby, format the data once, and then compare the cleaned version against the source so you can spot missing fields, unexpected wrappers, or type changes before they become bugs. When a tool produces output you plan to reuse in code, paste it into the actual place it will live, such as a model class, test fixture, or README snippet, and verify that the structure still makes sense after one more read-through. The goal is not just prettier output, but fewer mistakes when the data moves from a scratchpad into a real project.
Before you rely on any generated output, test one realistic example and one messy edge case. That habit catches the problems that only show up in production, such as null fields, nested arrays, unexpected text encoding, or inconsistent naming conventions. Good developer tools reduce friction, but the review step still belongs to you.
Frequently asked questions