URL Encoder & Decoder: Complete Guide to Percent Encoding
URLs can only contain a limited set of characters from the ASCII character set. When you need to include special characters, spaces, or non-English text in a URL, those characters must be “percent encoded” — replaced with a % symbol followed by their hexadecimal byte values. Our free URL encoder and decoder tool handles this conversion instantly, supporting both encoding (text → URL-safe) and decoding (URL-safe → readable text) with full RFC 3986 compliance.
What is Percent Encoding?
Percent encoding (also called URL encoding) is the mechanism for encoding characters that are not allowed in URLs or that have special meaning. Each encoded character is represented as a percent sign (%) followed by exactly two uppercase hexadecimal digits representing the character’s byte value in UTF-8.
For example: a space character (UTF-8 byte 0x20) becomes %20. An ampersand & (byte 0x26) becomes %26. The euro sign € (UTF-8 bytes E2 82 AC) becomes %E2%82%AC. The Japanese character 日 (UTF-8 bytes E6 97 A5) becomes %E6%97%A5.
This encoding ensures that URLs remain valid ASCII strings while carrying any Unicode content. Web servers and browsers handle the encoding/decoding transparently — users see readable URLs in the address bar (thanks to IRI support), while the actual HTTP request uses percent-encoded ASCII.
RFC 3986: The URL Standard
RFC 3986 (published January 2005) is the definitive specification for URI syntax. It categorizes characters into:
Unreserved characters (never need encoding):
A-Z a-z 0-9 - _ . ~
Reserved characters (have special URL meaning, encode only when used as data):
: / ? # [ ] @ ! $ & ’ ( ) * + , ; =
All other characters (must always be percent-encoded): spaces, < > { } | \ ^` and all non-ASCII characters. The standard also specifies that percent-encoded characters should use uppercase hex digits (e.g., %2F not %2f) for consistency.
Reserved Characters Reference Table
| Character | Encoded | URL Purpose |
|---|---|---|
| : (colon) | %3A | Scheme/port separator |
| / (slash) | %2F | Path separator |
| ? (question) | %3F | Query string start |
| # (hash) | %23 | Fragment identifier |
| & (ampersand) | %26 | Query param separator |
| = (equals) | %3D | Key-value separator |
| + (plus) | %2B | Space in form data |
| @ (at) | %40 | User info separator |
| space | %20 | Not allowed in URLs |
| % (percent) | %25 | Encoding escape character |
encodeURIComponent vs encodeURI in JavaScript
JavaScript provides two built-in encoding functions with critically different behaviors:
encodeURIComponent() encodes everything except: A-Z a-z 0-9 - _ . ~ ! ’ ( ) *. It encodes characters with URL meaning like / ? # & =. Use this for encoding individual parameter values, path segments, or any string that will be placed inside a URL component.
encodeURI() encodes everything except: unreserved chars plus ; , / ? : @ & = + $ # . It preserves URL structure characters. Use this only for encoding a complete URL where you want to preserve the scheme, host, path, and query structure.
Common mistake: Using encodeURI() for a query parameter value that contains & or = will NOT encode those characters, breaking the URL structure. Always use encodeURIComponent() for parameter values:
// WRONG: & is not encoded, creates a false parameter
encodeURI(“Tom & Jerry”) → “Tom%20&%20Jerry”
// CORRECT: & is safely encoded
encodeURIComponent(“Tom & Jerry”) → “Tom%20%26%20Jerry”
URL Encoding in Different Languages
Every programming language provides URL encoding functions:
- JavaScript:
encodeURIComponent()/decodeURIComponent() - Python:
urllib.parse.quote()/urllib.parse.unquote() - PHP:
urlencode()/urldecode()andrawurlencode() - Java:
URLEncoder.encode(str, “UTF-8”) - C#:
Uri.EscapeDataString()/HttpUtility.UrlEncode() - Go:
url.QueryEscape()/url.PathEscape() - Ruby:
CGI.escape()/URI.encode_www_form_component()
Note: PHP’s urlencode() encodes spaces as + (form encoding), while rawurlencode() uses %20 (RFC 3986). Python’s quote() uses %20 by default; pass quote_via=quote_plus for + encoding.
Common URL Encoding Scenarios
Search queries: When building a Google search URL, the query must be encoded: https://google.com/search?q=what+is+URL+encoding or ?q=what%20is%20URL%20encoding.
API parameters: REST APIs require encoded parameter values. If sending JSON as a parameter: the braces, quotes, and colons all need encoding. Example: ?filter=%7B%22name%22%3A%22test%22%7D.
File paths: Files with spaces or special characters in paths need encoding: /files/my%20document%20(final).pdf.
International domains: URLs with non-ASCII domain names use Punycode (xn-- prefix) for the domain and percent encoding for the path/query. Example: https://xn--n3h.com/%E4%B8%AD%E6%96%87.
Avoiding Double Encoding
Double encoding is one of the most common URL bugs. It happens when already-encoded text is encoded again: %20 becomes %2520 (because % is encoded as %25). This creates URLs that look right but don’t work — the server receives literal “%20” text instead of a space.
Prevention strategies: (1) Encode values at the point of URL construction, not before. (2) If unsure whether a string is already encoded, decode it first, then encode once. (3) Be aware that frameworks (Express.js, Django, Spring) often auto-encode URLs — don’t manually encode on top. (4) Use URL builder classes/libraries instead of string concatenation.
Form Encoding vs URL Encoding
HTML forms with method=“POST” and the default enctype=“application/x-www-form-urlencoded” use a slightly different encoding than RFC 3986 URLs. The key difference: spaces are encoded as + instead of %20. This legacy format comes from early HTML specifications and remains for backward compatibility.
In practice, most web servers accept both + and %20 as spaces in query strings. However, for non-form contexts (REST APIs, URL path segments, non-HTTP URIs), always use %20. When building URLs programmatically, prefer RFC 3986 encoding (%20) unless specifically constructing form data bodies.
Security Considerations in URL Encoding
URL encoding plays a critical role in web security. Improper encoding is the root cause of several vulnerability classes. Cross-Site Scripting (XSS) can occur when user input is inserted into URLs without proper encoding — a malicious <script> tag in a URL parameter becomes executable if decoded and rendered as HTML. Always encode user input before including it in URLs, and decode with caution.
Path traversal attacks exploit insufficient encoding validation: %2e%2e%2f (encoded ../) might bypass naive path checks that only look for literal ../ strings. Server-side code must normalize and validate paths after decoding. Open redirect vulnerabilities use encoded URLs to disguise malicious redirect destinations: ?redirect=%68%74%74%70%3A%2F%2Fevil.com might bypass URL validation that checks for the literal string “evil.com”.
Best security practices: always encode output (defense in depth), validate and sanitize input after decoding, use allowlists for URL parameters rather than blocklists, and never trust that URL encoding alone provides security — it’s an encoding scheme, not a sanitization mechanism.
URL Encoding in APIs and Web Services
RESTful APIs heavily rely on URL encoding. Query parameters with complex values (JSON objects, arrays, special characters) must be properly encoded. For example, filtering an API by date range: /api/events?start=2026-06-01T00%3A00%3A00Z&end=2026-06-30T23%3A59%3A59Z (colons encoded as %3A in parameter values).
OAuth and authentication flows use URL encoding extensively. OAuth 2.0 callback URLs must be exactly percent-encoded as registered. JWT tokens in URL parameters must have their dots (.) and base64 padding (=) properly handled. API keys containing special characters (+, /, =) from base64 encoding need percent-encoding when sent as query parameters. GraphQL over GET requires the entire query string to be URL-encoded, often resulting in very long encoded URLs that push the practical URL length limit (2,048 characters in older browsers, 8,192 in modern ones).
Webhook URLs present a unique challenge: they often contain authentication tokens in the path or query that include special characters. When sharing webhook URLs in documentation or configuration files, ensure they’re properly encoded. A common bug is copy-pasting a URL from a browser address bar (which may display decoded characters) into a configuration field that doesn’t re-encode automatically.
Frequently Asked Questions
What is URL encoding (percent encoding)?
URL encoding replaces unsafe characters with % followed by two hex digits. Space becomes %20, & becomes %26. This ensures URLs remain valid ASCII and special characters don’t break URL structure.
What is RFC 3986?
RFC 3986 is the internet standard defining URI syntax. It specifies which characters are unreserved (never encoded: A-Z, a-z, 0-9, -, _, ., ~), which are reserved (special URL meaning), and when percent encoding is required.
What is the difference between encodeURI and encodeURIComponent?
encodeURI preserves URL-meaningful characters (: / ? # & =) — use for complete URLs. encodeURIComponent encodes everything — use for parameter values. The wrong choice can break URLs or leave security vulnerabilities.
Which characters need to be encoded in URLs?
All characters except A-Z, a-z, 0-9, -, _, ., and ~ (unreserved). Reserved characters (: / ? # & = + @) must be encoded when used as data rather than as URL delimiters. Spaces and all non-ASCII require encoding.
Should spaces be encoded as %20 or +?
%20 is the RFC 3986 standard. + represents spaces only in HTML form data (application/x-www-form-urlencoded). Most servers accept both in query strings, but use %20 for paths and non-form contexts.
How do I encode Unicode characters in URLs?
First encode the character as UTF-8 bytes, then percent-encode each byte. For example, é (U+00E9) → UTF-8: C3 A9 → URL: %C3%A9. Modern languages handle this automatically in their URL encoding functions.
What is double encoding and how do I avoid it?
Double encoding turns %20 into %2520 (encoding the % again). Avoid by: encoding only once, decoding before re-encoding if unsure, being aware of framework auto-encoding, and using URL builder libraries.
What are reserved characters in URLs?
Reserved characters have structural meaning: : (port), / (path), ? (query), # (fragment), & (param separator), = (key-value), @ (userinfo). They must be encoded when used as literal data, not as delimiters.
Related Tools
- Unicode Converter — Convert text to Unicode code points and encodings
- Robots.txt Generator — Create robots.txt for web crawlers
- Tweet Character Counter — Count characters for social posts
- Text to Speech — Convert text to audio