URL Encode / Decode
Percent-encode or decode text and URLs. Choose component scope (encodeURIComponent, escapes the reserved delimiters) or whole-URI scope (encodeURI, keeps a full URL valid), toggle + vs %20 spaces, and break any URL into a decoded query-parameter table. Everything runs in your browser.
Component escapes the reserved delimiters & = ? / # : — use it for one query value, path segment or fragment.
A space becomes "%20" (standard percent-encoding — safe anywhere in a URL).
Processed entirely in your browser. Encoding and decoding use the browser's native encodeURIComponent/encodeURI — nothing you paste is sent anywhere.
What this tool is
- A free, in-browser URL encoder / decoder for percent-encoding — paste text or a URL and encode or decode it instantly, with nothing sent to a server.
- Two scopes, and getting this wrong is the usual bug: Component (encodeURIComponent) escapes the reserved delimiters & = ? / # : — use it for one query value or path segment; Whole URI (encodeURI) preserves them so an entire URL stays valid.
- Space handling is explicit: toggle between %20 (standard percent-encoding, safe anywhere) and + (the application/x-www-form-urlencoded query style).
- A query-string breakdown parses any pasted URL into a readable, editable key/value table of its decoded parameters — edit values and rebuild the URL.
- Security relevance: URL-encoding (and double-encoding) is how injection, XSS, SSRF and open-redirect payloads slip past naive filters, so reading what an encoded string actually decodes to is a core review skill.
What is URL (percent) encoding?
A URL can only safely carry a limited set of ASCII characters. Everything else — spaces, non-English letters, and the characters that have a structural meaning in a URL — has to be percent-encoded: replaced by a % followed by the two-digit hexadecimal value of each UTF-8 byte. A space becomes %20, an ampersand becomes %26, and é becomes %C3%A9. This is defined by RFC 3986, and every browser ships the exact encoders this tool uses.
Unreserved — never encoded
A–Za–z0–9-_.~Reserved — encoded by component scope
!#$&'()*+,/:;=?@[]encodeURIComponent vs encodeURI
This is the distinction almost everyone gets wrong, so the tool makes it an explicit choice:
| Scope | Function | Use it for |
|---|---|---|
| Component | encodeURIComponent | One query value, path segment or fragment. Escapes reserved delimiters (& = ? / # :). |
| Whole URI | encodeURI | An entire, already-structured URL. Preserves reserved delimiters so the URL stays valid; only escapes spaces and unsafe characters. |
Rule of thumb: build the URL structure yourself, then run each individual value through component encoding. Running whole-URI encoding over a value that contains its own & or = leaves those delimiters un-escaped and silently corrupts the query string.
Why it matters for security
Encoding is a standard evasion technique, so reading it fluently is a review skill. Attackers percent-encode — or double-encode (e.g. %253C decodes to %3C decodes to <) — the payloads for XSS, SQL injection, path traversal (..%2F), SSRF and open-redirect attacks, so a naive filter matching literal characters never sees them while the server decodes them back into the dangerous form before use. The defensive rule is to fully decode (canonicalise) input before you validate it, never after. Decode a suspicious string here, layer by layer, to see what it actually resolves to.
Worked examples
a b&c=d→a%20b%26c%3DdComponentThe & and = are escaped because they would otherwise be read as query delimiters.
https://x.com/a b?q=1&r=2→https://x.com/a%20b?q=1&r=2Whole URIOnly the space is escaped; the structural ? & / : survive so the URL stays valid.
<script>alert(1)</script>→%3Cscript%3Ealert(1)%3C%2Fscript%3EComponentAn XSS probe encoded for a parameter — and %253Cscript%253E would be the double-encoded evasion.
café→caf%C3%A9ComponentNon-ASCII is encoded as its UTF-8 bytes; decoding round-trips back to café.
Reference: RFC 3986 (URI syntax) and the WHATWG URL / application/x-www-form-urlencoded specifications. Encoding and decoding use the browser's native functions; nothing you enter leaves your browser.
Frequently asked questions
What is URL encoding?
URL encoding, also called percent-encoding, is the mechanism defined by RFC 3986 for representing characters in a URL that are either reserved (they have a structural meaning, like & ? / # =) or unsafe (spaces, non-ASCII letters, control characters). Each such byte is replaced by a percent sign followed by its two-digit hexadecimal value — a space becomes %20, an ampersand becomes %26, and the é in "café" becomes its UTF-8 bytes %C3%A9. Unreserved characters (A–Z, a–z, 0–9 and - _ . ~) are never encoded. Encoding lets you put arbitrary data into a URL without breaking its structure, and decoding reverses it.
What is the difference between encodeURIComponent and encodeURI?
encodeURIComponent encodes a single component — one query-parameter value, one path segment, or a fragment — so it escapes the reserved delimiters & = ? / # : @ + $ , as well. encodeURI is for an entire, already-structured URL, so it deliberately preserves those reserved delimiters and only escapes spaces and other unsafe characters, keeping the URL valid. The classic bug is using encodeURI on a value that itself contains an & or = (for example a search term): the delimiters survive un-escaped and corrupt the surrounding query string. Rule of thumb: build the URL structure yourself, then run each individual value through encodeURIComponent.
When should I use + versus %20 for a space?
Both decode to a space, but they come from different specs. %20 is the RFC 3986 percent-encoding of a space and is valid anywhere in a URL — path, query or fragment. The + convention comes only from the application/x-www-form-urlencoded format used for HTML form submissions and query strings, where a literal + means a space. Using + inside a path segment is wrong (a path + stays a +), and a server that is not form-decoding will show you a literal + instead of a space. When in doubt, use %20; use + only for query strings you know are parsed as form data. This tool lets you toggle between the two.
Why does URL encoding matter for security?
Encoding is a common evasion technique. Attackers URL-encode (or double-encode, e.g. %253C for <) payloads for XSS, SQL injection, path traversal (..%2F), SSRF and open-redirect attacks so that a naive input filter checking for literal characters never sees them, while the server or browser still decodes them back into the dangerous form before use. Reviewing a suspicious request or log line therefore means decoding every layer to see what it really resolves to — and when you build defences, you canonicalise (fully decode) input before validating it, never after. This tool decodes layer by layer so you can read what an encoded string actually is.