Encode and decode URLs instantly. Convert spaces to %20, special characters to percent encoding. Perfect for API requests, query parameters, and web development.
https://example.com/search?q=hello world
mailto:user@example.com?subject=Hello & Greeting
Price: $100 (20% off!)
https://example.com/café/résumé.pdf
Convert spaces to %20 for valid URLs. When you paste "https://example.com/hello world" into a browser, it breaks. Use our encoder to convert it to "hello%20world". Essential for sharing URLs with spaces in filenames, search queries, or folder paths.
Building API requests? Use "Encode Component" for query string values. If you're passing user input like "Price: $100 & free shipping" as a URL parameter, encode it to %24100%20%26%20free. Prevents API errors from special characters (&, =, ?, #).
Google Analytics shows URLs as "example.com/caf%C3%A9"—hard to read! Paste encoded URLs here to decode them back to readable text "café". Perfect for analyzing traffic sources, understanding UTM parameters, or debugging redirect URLs.
Creating mailto links with pre-filled subject/body? Encode special characters in subject lines. "Subject: Meeting @ 3PM (Conference Room #5)" becomes "Meeting%20%403PM%20%28Conference%20Room%20%235%29". Works on all email clients without errors.
Building a custom search URL? Encode user queries before adding to URL. "how to fix laptop?" becomes "how%20to%20fix%20laptop%3F". Use this for Google search URLs, site search features, or marketplace filters.
URLs with accents, emojis, or non-Latin characters need encoding. "café.com/résumé.pdf" → "caf%C3%A9.com/r%C3%A9sum%C3%A9.pdf". Ensures URLs work across all browsers and servers. Required for international websites and multilingual content.
| Function | Use Case | What It Encodes |
|---|---|---|
encodeURI |
Full URLs | Spaces, accents; keeps :/?#&= |
encodeURIComponent |
Query params | Everything except A-Z, 0-9, -_.~ |
Example: For API query ?name=John & Jane, use encodeURIComponent on "John & Jane" → "John%20%26%20Jane". For full URL like https://example.com/café, use encodeURI → "https://example.com/caf%C3%A9".
API Request:
Before: https://api.example.com/search?q=coffee shops near me
After: https://api.example.com/search?q=coffee%20shops%20near%20me
Google Search:
Before: https://google.com/search?q=c++ tutorial
After: https://google.com/search?q=c%2B%2B%20tutorial
File Download:
Before: https://cdn.example.com/files/2024 Report (Final).pdf
After: https://cdn.example.com/files/2024%20Report%20(Final).pdf
A URL may only contain a limited set of ASCII characters, and several of those have reserved jobs: ? starts the query string, & separates parameters, = assigns values, # marks a fragment, / separates path segments. Any character that's outside the allowed set — spaces, accented letters, emoji — or that would collide with those jobs must be percent-encoded: replaced by % plus the hex value of its UTF-8 bytes. A space becomes %20, & becomes %26, and é becomes %C3%A9 (two bytes, two escapes).
Get this wrong and things break subtly: a search for "black & white" sent unencoded becomes a parameter q=black plus a mystery parameter white, because the raw ampersand split the query. Redirect URLs passed as parameters — ?next=https://example.com/page?id=5 — are the classic production bug: without encoding, the inner ? and & get parsed as part of the outer URL.
The most common encoding mistake is running a complete URL through an encoder: that turns the structural :// and / into %3A%2F%2F and breaks the link. The rule is: encode each value before assembling, never the assembled URL. In JavaScript this is the difference between encodeURIComponent() (aggressive — for parameter values) and encodeURI() (gentle — leaves URL structure alone). When debugging, the reverse skill matters more: paste any gnarly URL from logs or an email tracker into the decoder to see what's actually inside it — decoded UTM parameters and redirect chains are often eye-opening.
Related encodings live one tool over: Base64 for arbitrary binary data in text contexts, and the JWT Decoder for the base64url tokens that ride inside auth headers.
Both mean "space", but + is only valid in query strings (a legacy of HTML form encoding), while %20 is valid everywhere in a URL. When in doubt, use %20 — every parser accepts it.
That's double encoding: %20 was encoded again, turning its % into %25. It happens when two layers of a system both encode. Decode twice here to see the original, then fix the code path that encodes redundantly.
Yes — non-ASCII characters are percent-encoded as their UTF-8 bytes. Browsers display münchen.de/straße prettily but transmit the encoded form under the hood.
Yes — encoding and decoding run entirely in your browser. URLs with embedded tokens or session IDs never leave your machine.
The text either wasn't percent-encoded (decoding random text with stray % signs fails) or was encoded with a non-UTF-8 charset by a legacy system. Try decoding just the suspicious segment rather than the whole string.