If you've ever seen a URL with %20 or %3D in it and wondered what those percent signs mean, you've encountered URL encoding — the system that makes web addresses safe to transmit across the internet. This guide explains exactly how it works and when you need to use it.
Why URL Encoding Exists
URLs can only contain a limited set of safe ASCII characters: letters (A–Z, a–z), digits (0–9), and a handful of special characters (-, _, ., ~). Every other character — spaces, slashes, ampersands, accented letters, emoji — must be "percent-encoded" before they can be safely placed inside a URL.
Without encoding, a space in a URL would simply break the link. A browser or server would interpret it as the end of the URL. Percent encoding solves this by representing each unsafe character as a percent sign followed by two hexadecimal digits representing the character's UTF-8 byte value.
What %20 Actually Means
The space character has the ASCII code 0x20 in hexadecimal. So when a space appears inside a URL where it isn't allowed, it gets encoded as %20. For example:
New York→New%20Yorkhello world→hello%20world
Your browser usually handles this for you automatically when you type in the address bar, but as a developer you often need to encode URLs manually in JavaScript, Python, or server-side code.
%20 vs + for Spaces
You may have seen URLs that use + instead of %20 for spaces. Both are valid in specific contexts, but they're not interchangeable:
%20is the standard RFC 3986 encoding for a space in any URL component (path, fragment, header value).+as a space is only valid in query strings (the part after?) and is a legacy convention from HTML form submission (application/x-www-form-urlencoded). It is not a valid encoding for a space in a URL path.
Mixing them up is a common source of bugs. A URL like /search?q=new+york works correctly because it's a query string, but /cities/new+york would be treated as a literal plus sign in the city name.
Common Characters and Their Encoded Forms
&→%26(critical — & separates query params, must be encoded when used as data)=→%3D(must be encoded in values, since = separates query param names from values)/→%2F(only when / is data, not a path separator)?→%3F(must be encoded in path segments)#→%23(hash marks the start of a fragment; encode it when it's data)@→%40+→%2B(in contexts using + for spaces, a literal plus must be encoded)
Encoding in JavaScript
JavaScript has two functions for URL encoding:
encodeURIComponent(str)— encodes everything except standard unreserved characters. Use this for individual values inside URLs (search queries, parameter values, path segments).encodeURI(str)— encodes a full URL, but preserves structural characters like?,&,/. Use this only when encoding a complete, pre-built URL.
A very common mistake is using encodeURI on a value that will be placed inside a URL — this leaves characters like & and = unencoded, which breaks the URL structure. Always use encodeURIComponent for values.
Quick Tip: Encode and Decode Instantly
You can encode or decode any URL string immediately using the Toolskuy URL Encoder / Decoder. It handles bulk input, supports all edge cases, and shows you the decoded human-readable form side-by-side with the encoded form — useful for debugging API responses and query strings.
Frequently Asked Questions
Is URL encoding the same as HTML encoding? No. HTML encoding (also called HTML entity encoding) converts characters like < and > into < and > so they render correctly inside HTML. URL encoding converts characters into percent-hex sequences for safe transmission in URLs. They're separate systems that each solve different problems.
Do I need to decode URLs before storing them in a database? Generally yes — store the decoded, human-readable form in your database and re-encode only when building URLs for output. This avoids double-encoding bugs and makes data more readable in queries.
What about Unicode characters in URLs? Accented characters and non-Latin scripts (Arabic, Chinese, emoji) are first encoded as UTF-8 bytes, then each byte is percent-encoded. For example, the ñ character encodes to %C3%B1 because its UTF-8 representation is the two bytes 0xC3 and 0xB1.