Sponsored placement
What Is URL Encoding (Percent-Encoding)?
URL encoding, also called percent-encoding, replaces characters that are not valid inside a URL with a percent sign followed by two hexadecimal digits. A space becomes %20, an ampersand becomes %26, and an equals sign becomes %3D. This encoding is required because URLs can only safely contain a limited set of ASCII characters defined in RFC 3986.
JavaScript provides two functions for URL encoding: encodeURIComponent and encodeURI. encodeURIComponent encodes all characters except unreserved characters — letters, digits, hyphens, underscores, periods, and tildes. It is the correct function for encoding individual query parameter values or path segments. encodeURI leaves structural URL characters like forward slash, colon, question mark, ampersand, and hash intact so the URL structure remains valid.
When you submit an HTML form, the browser encodes field values using application/x-www-form-urlencoded encoding, which uses a plus sign for spaces instead of %20. This is a separate standard, which is why you sometimes see plus signs in query strings from form submissions and %20 in URLs built in JavaScript.
- Space encodes as %20 (or + in HTML form data)
- Ampersand encodes as %26 — critical in query strings where & separates parameters
- Equals sign encodes as %3D when it appears as a value, not as a separator
- Forward slash encodes as %2F when it appears in a value, not a path separator
- Hash sign encodes as %23 to prevent the browser treating it as a fragment
- Plus sign encodes as %2B when a literal plus is needed rather than a space
When to Encode and When to Decode
Encode when you are building a URL dynamically and need to put user-supplied text, search terms, or any string with special characters into a query parameter or path segment. Failing to encode user input in URLs can result in broken requests, truncated values when an unencoded ampersand appears inside a value, or security issues if the raw input is reflected back to other users.
Decode when you are reading a URL that arrived via a redirect, an API response, a server log, or a referral parameter and you need to see the original value. Log files and server-side frameworks often leave URLs in percent-encoded form. Decoding them makes them readable and easier to debug.
A common real-world case is OAuth authentication. The authorization server redirects users back to a callback URL. If that callback URL contains special characters and was not encoded when building the authorization request, the redirect breaks. Using a URL encoder to verify the correct encoded form of your callback URL before setting it in your authorization flow prevents this problem.
URL Encoding vs Base64 Encoding
URL encoding and Base64 encoding solve different problems. URL encoding replaces individual special characters with percent-encoded sequences. The output is still recognizably the original text with some characters replaced — a URL remains a readable URL after percent-encoding.
Base64 encoding converts any arbitrary binary data or text into a string of 64 ASCII characters. The original content is not human-readable without decoding. Base64 is used when binary data needs to be included in contexts that only accept text — embedding images inline in CSS or HTML, sending binary payloads in JSON, or transmitting binary content in email.
Use URL encoding for query strings, path segments, and URL parameters. Use Base64 when encoding binary data that will be embedded in text-based formats or transmitted through channels that are not binary-safe. The two encodings are not interchangeable and should not be substituted for one another.
Why marketers use this tool
- Encode any URL component using the browser-native encodeURIComponent standard
- Decode percent-encoded strings back to human-readable text in one click
- Fully client-side — your data never leaves your browser
Frequently Asked Questions
What is the difference between encodeURIComponent and encodeURI?
encodeURIComponent encodes all characters except letters, digits, hyphens, underscores, periods, tildes, exclamation marks, asterisks, and parentheses. It is the correct function for encoding individual query parameter values. encodeURI leaves structural URL characters like forward slash, colon, question mark, ampersand, equals, and hash intact. Use encodeURIComponent for values that go inside query parameters and encodeURI only when encoding a full URL while preserving its structure.
Why does a space appear as + sometimes and %20 other times?
Both represent a space but in different encoding standards. %20 is the standard percent-encoding from RFC 3986 and is what encodeURIComponent produces. The plus sign encoding for spaces comes from the older application/x-www-form-urlencoded format used in HTML form submissions. Most web servers and APIs accept both, but APIs built on strict RFC 3986 compliance expect %20 in path segments and query strings.
How do I decode a URL in JavaScript?
Use decodeURIComponent() to decode individual query parameter values or path segments that were encoded with encodeURIComponent. Use decodeURI() to decode a full URL encoded with encodeURI. If you pass a malformed percent-encoded sequence to decodeURIComponent — such as a bare percent sign or a percent sign followed by non-hex characters — JavaScript throws a URIError. Wrap the call in a try-catch when decoding user-supplied input.
What characters are safe in URLs without encoding?
RFC 3986 defines the unreserved characters that are safe without encoding: uppercase and lowercase letters, digits 0 through 9, hyphen, underscore, period, and tilde. All other characters, including spaces, ampersands, hash signs, equals signs, and non-ASCII characters, must be percent-encoded when they appear as literal values in query parameters or path segments.
What is double encoding and why is it a problem?
Double encoding happens when a value that is already percent-encoded gets encoded a second time. The percent sign itself gets encoded as %25, so %20 (an encoded space) becomes %2520. When the server decodes the URL, it receives the literal string %20 instead of a space. Always check whether a value is already encoded before encoding it again to avoid this problem.