URL Encoder / Decoder
Paste text to URL-encode it (percent-encoding) or paste an encoded string to decode it back. Handles special characters, spaces, Unicode, and query parameters.
URLs were designed in 1994 to use only a limited ASCII subset. Spaces, accented letters, emoji, ampersands, equals signs — anything outside the safe set — has to be "percent-encoded" before it can travel safely through a URL. A space becomes %20, an ampersand becomes %26, and a non-ASCII character is first UTF-8 encoded then percent-encoded byte by byte (so "é" becomes %C3%A9). Every web framework, mobile app, and browser does this automatically when you build URLs the right way; this tool does it manually when you need to debug or hand-craft one.
This page encodes and decodes URLs using the modern `encodeURIComponent` rules — the safer of the two JavaScript URL-encoding functions. Paste plain text into the encoder to get a query-parameter-safe string; paste a percent-encoded string into the decoder to recover the original text. Common use cases: constructing API request URLs by hand, debugging webhook payloads, decoding email tracking links, or unescaping a string copied from a server log.
Two things to keep in mind: URL encoding and HTML encoding are different (& vs &), and you can over-encode (encoding a string twice produces %2520 instead of %20 for a space). Both errors are easy to spot once you know the pattern.
Enter text to encode
Result
Results
Mode
Encode
Input Length
0
Output Length
0
Formula
How to use this calculator
- To encode: paste your plain text in the encoder input. The output is percent-encoded with all reserved characters escaped.
- To decode: paste a percent-encoded string in the decoder input. The output is the original plain text.
- For URL paths (the part before ?): use encodeURI to leave / and : alone.
- For query parameter values: use encodeURIComponent (this tool's default).
- For email mailto: links and tel: URIs: percent-encode any spaces or special characters in subjects or body text.
- For JSON in query strings: encode the whole JSON string after stringify — every {, }, ", and : gets encoded.
Worked examples
Building a search URL with special characters
**Scenario:** You're building a search URL with the query "hello world! foo=bar" for a search engine. **Calculation:** Plain: `hello world! foo=bar`. Encode: spaces → %20, ! → %21, = → %3D. Result: `hello%20world%21%20foo%3Dbar`. Final URL: `https://example.com/search?q=hello%20world%21%20foo%3Dbar`. **Result:** The encoded query travels safely. Without encoding, the = and ! could be misinterpreted as URL syntax, and spaces would break the URL entirely (browsers might tolerate them but proxies and CDNs often won't).
Decoding a redirect URL parameter
**Scenario:** A webhook log shows a redirect URL: `https://app.example.com/auth?return=%2Fdashboard%3Ftab%3Dprofile%26mode%3Dedit`. What does the return parameter actually point to? **Calculation:** Decode `%2Fdashboard%3Ftab%3Dprofile%26mode%3Dedit`: %2F → /, %3F → ?, %3D → =, %26 → &. Result: `/dashboard?tab=profile&mode=edit`. **Result:** The return URL points to /dashboard with query parameters tab=profile and mode=edit. Encoding lets a URL be passed as a single parameter value without confusing the host URL's parser.
Catching a double-encoded URL bug
**Scenario:** You see "%2520" in a URL log instead of the expected space. What happened? **Calculation:** "%2520" is "%" (encoded as %25) followed by "20". This means the original space was encoded once (→ %20), then the entire string was encoded again, turning the % into %25 and producing "%2520". **Result:** Double encoding. Common cause: a client encodes, sends to a server, and the server (or a middleware library) encodes again before forwarding. Fix by encoding once at the boundary and trusting downstream code to pass through.
When to use this calculator
**Use URL encoding when you need to:**
- **Build API request URLs by hand**: query parameter values containing spaces, ampersands, or quotes must be encoded. - **Debug webhook payloads or redirect chains**: encoded URLs hide the real destination until you decode them. - **Pass JSON or structured data through a URL parameter**: the entire stringified JSON gets percent-encoded. - **Construct mailto: or tel: URIs**: `mailto:?subject=Hello%20World&body=Test` — spaces and ampersands need encoding. - **Work with OAuth or SSO redirects**: `redirect_uri` and `state` parameters are routinely encoded values containing other URLs. - **Read or write `.url` shortcut files, browser history, or analytics logs**: many systems store URLs in encoded form.
**Encoding pitfalls in real systems:**
- **Browsers display encoded URLs differently**: Chrome shows %20 but pastes the literal space; copy-paste roundtrip can lose encoding. - **Some servers double-decode**: NGINX → app → framework chains might each decode the URL, leading to security holes if the original had encoded slashes (%2F). - **Path vs query semantics differ**: `/foo/bar` vs `/foo%2Fbar` are different paths but the same query string value. - **HTML attributes use & not &** in src/href once decoded — but the HTML *source* needs & to be valid HTML.
**When you should NOT URL-encode:**
- Hostnames (use Punycode for IDNs, not percent-encoding). - The protocol scheme (https://, mailto:) — these are literal. - Already-encoded strings (double encoding is a bug). - The whole URL when it's already a valid URL — encode only the parts you're adding.
Common mistakes to avoid
- Confusing URL encoding with HTML entity encoding. URL encoding uses %20; HTML uses & or  . They're different schemes.
- Double encoding. Calling encodeURIComponent twice on the same string turns "hello world" into "hello%2520world".
- Encoding the protocol or hostname. "https%3A%2F%2Fexample.com" is broken — only the path/query/fragment should be encoded, not the scheme or host.
- Using encodeURI when you need encodeURIComponent. `encodeURI` leaves &, =, +, etc. alone, which breaks query parameters that contain those characters.
- Trusting + as space everywhere. In path segments, "+" is a literal plus, not a space. Only in application/x-www-form-urlencoded query strings does "+" mean space.
- Forgetting that # is special. The fragment (#section) is never sent to the server. Encoding # as %23 makes it part of the URL path/query, not a fragment.
- Encoding the / in path segments accidentally. Use encodeURIComponent only on the segment text; assemble the full path with literal slashes between segments.