Building Secure Web Applications?
Our developers implement proper encoding, input validation, and XSS prevention.
What Is URL Encoding
URL encoding (also called percent-encoding) converts characters into a format that can be safely transmitted in a URL. URLs can only contain a limited set of ASCII characters: letters, digits, and a few special characters like hyphens and underscores. Any other character—spaces, non-ASCII letters, special symbols—must be encoded as a percent sign followed by two hexadecimal digits representing the character's byte value.
This encoding scheme is defined in RFC 3986 and is fundamental to how the web works. Every time you search for something with spaces, submit a form, or share a URL containing special characters, URL encoding is happening behind the scenes. Understanding it is essential for web developers, API designers, security professionals, and anyone working with HTTP requests.
How URL Encoding Works
URL encoding replaces unsafe characters with a percent sign (%) followed by their hexadecimal ASCII value. Multi-byte characters (like Unicode) are first encoded in UTF-8, then each byte is percent-encoded individually.
| Character | Encoded | Reason |
|---|---|---|
| Space | %20 or + | Delimiter in URLs |
| & | %26 | Query parameter separator |
| = | %3D | Key-value pair separator |
| ? | %3F | Query string start marker |
| # | %23 | Fragment identifier |
| / | %2F | Path separator |
| @ | %40 | Userinfo separator |
| + | %2B | Interpreted as space in forms |
| % | %25 | Encoding escape character itself |
Reserved characters have special meaning in URLs (/, ?, &, =, #, @). They must be encoded when used as data rather than as delimiters. Unreserved characters (A-Z, a-z, 0-9, -, _, ., ~) never need encoding.
For example, searching for "C++ programming" in a query string becomes: q=C%2B%2B+programming or q=C%2B%2B%20programming.
Common Use Cases
- API development: Encode query parameters containing special characters, spaces, or Unicode text
- Form submissions: HTML forms encode field values before sending them in POST or GET requests
- URL construction: Build URLs programmatically with dynamic segments that may contain reserved characters
- Security testing: Test for URL-based injection vulnerabilities by encoding payloads
- Deep linking: Create shareable URLs with parameters that include special characters or non-English text
Best Practices
- Encode data, not structure — Only encode the values within query parameters, not the delimiters (?, &, =) themselves
- Use language-native functions — JavaScript's
encodeURIComponent(), Python'surllib.parse.quote(), and similar built-in functions handle encoding correctly - Don't double-encode — Encoding an already-encoded string produces invalid URLs (e.g., %20 becomes %2520)
- Always use UTF-8 — UTF-8 is the universally accepted encoding for URLs per RFC 3986; avoid legacy encodings like Latin-1
- Decode for display, encode for transport — Show human-readable URLs in the browser address bar but always encode values in HTTP requests
References & Citations
- Wikipedia. (2024). Percent-encoding (URL Encoding). Retrieved from https://en.wikipedia.org/wiki/Percent-encoding (accessed January 2025)
- T. Berners-Lee et al.. (2005). RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. IETF. Retrieved from https://datatracker.ietf.org/doc/html/rfc3986 (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
Frequently Asked Questions
Common questions about the URL Encode/Decode with Query Parser
URL encoding (percent-encoding) converts special characters to safe format for URLs using %XX notation where XX is hexadecimal ASCII code. Example: space becomes %20, @ becomes %40. Necessary because: URLs only support ASCII characters, special characters have meaning in URLs (? starts query, & separates parameters, # is fragment), spaces not allowed, non-ASCII characters (中文, émoji) need encoding. Without encoding: "https://site.com?search=hello world" breaks (space invalid). Encoded: "?search=hello%20world". Used in: query parameters, path segments, form data. Not needed in: domain names (use punycode), within HTML (different escaping). This tool encodes/decodes instantly.
encodeURI encodes full URL, preserving URL structure characters (:, /, ?, &, #). Example: encodeURI("http://example.com/path?q=hello world") = "http://example.com/path?q=hello%20world". encodeURIComponent encodes URI parts, encodes ALL special characters including URL structure. Example: encodeURIComponent("hello world&foo=bar") = "hello%20world%26foo%3Dbar". Use encodeURI for: complete URLs before sending. Use encodeURIComponent for: query parameter values, form inputs, API parameters. Common mistake: using encodeURI on query values - breaks &, =. Best practice: encodeURIComponent for all user input in URLs. This tool supports both modes with visual difference comparison.
Reserved characters (special meaning): : / ? # [ ] @ ! $ & ( ) * + , ; = - must encode in data, not structure. Unsafe characters: space " < > % { } | \ ^ ~ [ ] ` - always encode. Non-ASCII: 中文, émojis, accents (é, ñ) - encode. Unreserved (safe, no encoding needed): A-Z a-z 0-9 - _ . ~. Example: "hello world!" → "hello%20world%21". Common encodings: space = %20 or +, @ = %40, # = %23, & = %26, = = %3D. Double encoding: avoid encoding twice (%20 → %2520). Decode before re-encoding. This tool highlights which characters require encoding and provides character encoding reference.
Query strings start with ? and use & to separate parameters. Format: ?key1=value1&key2=value2. Encode each value separately: ?search=encodeURIComponent(userInput). Example: search="coffee & tea" → ?search=coffee%20%26%20tea. Array parameters: ?tags[]=a&tags[]=b or ?tags=a,b (depends on server). Spaces: %20 or + (both valid in query strings). Equals in value: encode = as %3D. Ampersand in value: must encode & as %26 (otherwise starts new parameter). Build query: use URLSearchParams (JavaScript) or http.build_query (PHP). Never concatenate manually: "?search=" + input (unsafe!). This tool safely encodes query parameters with proper & and = handling.
Different contexts, different encoding. URL encoding: for URLs and URIs, uses %XX hexadecimal, space = %20, < = %3C. HTML encoding: for HTML content, uses &name; entities, space = (non-breaking) or plain space, < = <. Example: "a<b&c>d" in URL: "a%3Cb%26c%3Ed", in HTML: "a<b&c>d". Context matters: URL parameter with HTML content needs both: encodeURIComponent("a") = "a%3Cb%3E", then in HTML: <a href="?q=a%3Cb%3E">. Don't mix: using %20 in HTML shows literally, using < in URL breaks. This tool focuses on URL encoding - use HTML encoder for HTML entities.
URL paths (between slashes): encode most special characters but / separates path segments. Example: /api/users/john%20doe (space encoded, / not). Some servers allow: - _ . ~ in paths unencoded. Query strings (after ?): encode = & ? # since they have special meaning. Example: ?name=john%26jane (& must be encoded). Fragment (after #): similar to query encoding. Best practices: always encode user input regardless of position, encodeURIComponent for both paths and queries is safe, server frameworks handle decoding automatically. Double slashes: avoid // in paths (may normalize to /). This tool helps identify correct encoding per URL component.
Double encoding: encoding already-encoded URL. "hello%20world" → "hello%2520world" (wrong). Check before encoding. Not encoding user input: leaving special characters unencoded creates XSS vulnerabilities. Always encode untrusted input. Using encodeURI on parameters: preserves &, = (breaks query string). Use encodeURIComponent for parameter values. Encoding too much: encoding entire URL with structure makes http become http%3A%2F%2F. Encode parts separately. Forgetting to decode: displaying "hello%20world" to user (shows %20). Decode for display. Plus sign ambiguity: + can mean space in query strings but not in paths. Use %20 for clarity. Wrong encoding in POST body: use application/x-www-form-urlencoded header. This tool prevents double-encoding and validates output.
Non-ASCII characters (中文, émoji, é) convert to UTF-8 bytes then percent-encode each byte. Example: "café" → c (63) a (61) f (66) é (C3 A9 in UTF-8) → "caf%C3%A9". Emoji "😀" → %F0%9F%98%80 (4 bytes). Modern browsers handle automatically, but APIs may need explicit encoding. Punycode for domains: "münchen.de" → "xn--mnchen-3ya.de" (different encoding). IDN (Internationalized Domain Names) handled separately from path/query encoding. Best practice: use UTF-8 everywhere, let libraries handle encoding (encodeURIComponent uses UTF-8), test with actual international characters. This tool correctly handles UTF-8 multibyte characters and shows byte-level encoding.