Percent Encode

Q: Why do I see %2B instead of + in encoded output?

A literal plus sign (+) in data must be percent-encoded as %2B to avoid ambiguity. In URLs, the + character has special meaning in query strings—it represents a space (legacy behavior from form submissions). When your data contains an actual plus sign that should be preserved (e.g., "C++", "email+tag@example.com", "2+2=4"), it must be encoded as %2B. Otherwise, servers will decode + as a space, corrupting your data. The encoder treats + as a literal character requiring encoding, while spaces can be encoded as either %20 or + (though %20 is recommended for clarity). This prevents the ambiguity where "hello+world" could mean "hello world" or "hello+world" depending on context.

Q: Should I encode the full URL or just parameters?

Encode parameter values and path segments individually, never the entire URL. Full-URL encoding converts essential delimiters (://?#&=) into %XX sequences, breaking URL structure. For example, encoding https://api.example.com/search?q=hello world produces https%3A%2F%2Fapi.example.com%2Fsearch%3Fq%3Dhello%20world , which is unreadable as a URL. Instead, encode only the query value: https://api.example.com/search?q=hello%20world . Similarly for paths, encode /files/my file.pdf as /files/my%20file.pdf , not %2Ffiles%2Fmy%20file.pdf . Use encodeURIComponent() for values, encodeURI() for partial URLs that preserve structure.

Q: How do I detect double encoding?

Double encoding happens when you encode already-encoded data, producing sequences like %2520 (which is %25 = % followed by 20). If decoded output still contains many unexpected %XX sequences, you likely encoded twice. Example: encoding "hello world" produces "hello%20world". Encoding that again produces "hello%2520world" because the % in %20 becomes %25. To detect: decode once and check if output looks correct. If it still has %XX, decode again. Prevention: before encoding, check if data already contains %XX patterns. If unsure, decode first, then re-encode. Many bugs occur when both client-side JavaScript and server-side code encode the same parameter, causing double encoding that breaks string matching and database queries.

Q: Which specification governs percent encoding?

RFC 3986 defines URI percent-encoding rules, specifying which characters are reserved (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) and when they must be percent-encoded. Reserved characters have special meaning in URLs—they delimit components—so they must be encoded when used as literal data. Unreserved characters (A-Z, a-z, 0-9, - . _ ~) never need encoding. Everything else, including spaces and non-ASCII characters, must be encoded. RFC 3986 also defines how to encode non-ASCII: first convert to UTF-8 bytes, then percent-encode each byte. Following RFC 3986 ensures your URLs work with all standard HTTP clients, servers, and proxies. When in doubt, encode more rather than less—servers handle encoded data correctly, but unencoded special characters cause parsing failures.

Percent encode URLs, query parameters, and form data instantly for RFC 3986 compliance. Convert spaces, special characters, and non-ASCII text to %XX format for safe transmission in HTTP requests, API calls, and browser URLs.

Why Use Percent Encode

Percent encoding (URL encoding) transforms unsafe characters into %XX hexadecimal sequences so URLs can safely travel through HTTP without corruption. When building query strings, API endpoints, or form submissions, special characters like spaces, ampersands, equals signs, and non-ASCII text must be percent-encoded to avoid breaking URL parsing. This tool encodes individual URL components—query values, path segments, or form data—preventing "400 Bad Request" errors and ensuring URLs work across all browsers and servers.

Query parameter safety: Encode values with spaces, &, =, +, ?, # to prevent parsing errors
Non-ASCII support: Handle Unicode characters, emojis, and international text in URLs
Form data encoding: Prepare POST body data with application/x-www-form-urlencoded format
Path segment encoding: Encode URL path parts containing slashes or special chars
Browser-safe: All encoding happens locally—no server uploads

Percent Encode Now →

Choose the Right Variant

This page: Percent encoding for URL components and form data (RFC 3986)
Encode URL: General URL encoding tool
URL Encoder Online: Quick URL encoding interface
Decode URL: Reverse percent encoding to readable text

Step-by-Step Tutorial

Identify the URL component to encode: query value, path segment, or form field
Example query value: search terms with spaces & symbols!
Paste into percent encoder input field
Encoded output: search%20terms%20with%20spaces%20%26%20symbols!
Build full URL: https://api.example.com/search?q=search%20terms%20with%20spaces%20%26%20symbols!
Test the URL in your API client or browser to verify it works

Real-World Use Case

A developer builds a search API endpoint that accepts user queries via URL parameters. When users search for "coffee & tea", the JavaScript code constructs https://api.example.com/search?q=coffee & tea. The unencoded ampersand breaks URL parsing—servers interpret it as a second parameter. The request fails with "400 Bad Request: Invalid query string." The developer percent-encodes the query value: coffee%20%26%20tea, and the URL becomes ?q=coffee%20%26%20tea. Now the API correctly receives "coffee & tea" as a single query value. They update their code to always percent-encode user input before building URLs. Search functionality works perfectly, even for queries with special characters, quotes, slashes, and emojis. Total debugging time: 10 minutes instead of hours tracing malformed HTTP requests.

Best Practices

Encode individual query parameter values, not the entire URL (preserve ? and & delimiters)
Use %20 for spaces in query strings (both %20 and + work, but %20 is standard)
Don't double-encode—decode first if unsure whether value is already encoded
Encode path segments separately to preserve forward slashes as delimiters
Always encode user input before embedding in URLs to prevent injection attacks
Use encodeURIComponent() in JavaScript, urllib.parse.quote() in Python for automatic encoding
Verify encoded URLs by pasting into a browser address bar and checking for errors

Performance & Limits

Encoding speed: Instant (< 5ms) for typical query strings
Maximum length: Handles URLs up to 100,000 characters
Browser support: Works in all modern browsers
Offline capability: Fully functional offline after page loads
No rate limits: Encode unlimited URL components locally

Common Mistakes to Avoid

Encoding entire URLs: Only encode parameter values and path segments—preserve scheme, domain, and delimiters
Space encoding confusion: + works in query strings but use %20 for consistency
Double encoding: Encoding "hello%20world" produces "hello%2520world"—always decode before re-encoding
Not encoding user input: Raw user text in URLs causes injection vulnerabilities and parsing errors
Wrong encoding for context: Use percent encoding for URLs, not Base64 or other formats
Missing reserved characters: ? & = # / should be encoded in values, not in structure

Privacy and Data Handling

All percent encoding happens locally in your browser using JavaScript. Your data never leaves your device and is never uploaded to any server. However, remember that percent encoding is not encryption—it only makes characters URL-safe. Encoded URLs containing sensitive data (API keys, tokens, personal information) are still readable by decoding %XX sequences. Never put sensitive credentials in query parameters, even when percent-encoded. Use Authorization headers or POST body encryption for secure data transmission. For debugging URLs with sensitive data, use this tool in private browsing mode.

Frequently Asked Questions

Why do I see %2B instead of + in encoded output?

A literal plus sign (+) in data must be percent-encoded as %2B to avoid ambiguity. In URLs, the + character has special meaning in query strings—it represents a space (legacy behavior from form submissions). When your data contains an actual plus sign that should be preserved (e.g., "C++", "email+tag@example.com", "2+2=4"), it must be encoded as %2B. Otherwise, servers will decode + as a space, corrupting your data. The encoder treats + as a literal character requiring encoding, while spaces can be encoded as either %20 or + (though %20 is recommended for clarity). This prevents the ambiguity where "hello+world" could mean "hello world" or "hello+world" depending on context.

Should I encode the full URL or just parameters?

Encode parameter values and path segments individually, never the entire URL. Full-URL encoding converts essential delimiters (://?#&=) into %XX sequences, breaking URL structure. For example, encoding https://api.example.com/search?q=hello world produces https%3A%2F%2Fapi.example.com%2Fsearch%3Fq%3Dhello%20world, which is unreadable as a URL. Instead, encode only the query value: https://api.example.com/search?q=hello%20world. Similarly for paths, encode /files/my file.pdf as /files/my%20file.pdf, not %2Ffiles%2Fmy%20file.pdf. Use encodeURIComponent() for values, encodeURI() for partial URLs that preserve structure.

How do I detect double encoding?

Double encoding happens when you encode already-encoded data, producing sequences like %2520 (which is %25 = % followed by 20). If decoded output still contains many unexpected %XX sequences, you likely encoded twice. Example: encoding "hello world" produces "hello%20world". Encoding that again produces "hello%2520world" because the % in %20 becomes %25. To detect: decode once and check if output looks correct. If it still has %XX, decode again. Prevention: before encoding, check if data already contains %XX patterns. If unsure, decode first, then re-encode. Many bugs occur when both client-side JavaScript and server-side code encode the same parameter, causing double encoding that breaks string matching and database queries.

Which specification governs percent encoding?

RFC 3986 defines URI percent-encoding rules, specifying which characters are reserved (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) and when they must be percent-encoded. Reserved characters have special meaning in URLs—they delimit components—so they must be encoded when used as literal data. Unreserved characters (A-Z, a-z, 0-9, - . _ ~) never need encoding. Everything else, including spaces and non-ASCII characters, must be encoded. RFC 3986 also defines how to encode non-ASCII: first convert to UTF-8 bytes, then percent-encode each byte. Following RFC 3986 ensures your URLs work with all standard HTTP clients, servers, and proxies. When in doubt, encode more rather than less—servers handle encoded data correctly, but unencoded special characters cause parsing failures.