URL Encode / Decode
Paste URL text to encode or decode instantly.
Upload a .txt file (max 5MB)
Important: This Tool Encodes Components, Not Whole URLs
Under the hood, both buttons here call JavaScript's encodeURIComponent() / decodeURIComponent() — not encodeURI(). That's the correct choice for encoding a single value (a query parameter, a form field, a path segment) but it has a real consequence you need to know if you paste in a complete URL: encodeURIComponent also escapes characters that are structurally meaningful in a full URL — / ? : @ & = + $ # — because it assumes everything you give it is a single opaque value, not a URL with structure.
Concretely: paste https://example.com/search?q=cats&page=2 into this tool and hit Encode, and you'll get back https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dcats%26page%3D2 — every slash, colon, question mark, and ampersand escaped, which is not a usable URL and not what encodeURI() would have produced (it would have left the scheme, slashes, and structural punctuation alone and only escaped genuinely unsafe characters). Use this tool to encode the value you're about to insert into a query string — like turning cats & dogs into cats%20%26%20dogs before appending it as ?q=cats%20%26%20dogs — not to encode a URL you intend to keep navigable as a whole.
The Double-Encoding Trap
Because % is itself not an unreserved character, encoding already-encoded text escapes the percent signs a second time: encode hello%20world again and you get hello%2520world (the %20's own % became %25). This is one of the most common real bugs in web apps that pass URLs through multiple layers (a redirect, then a proxy, then a client-side router) each applying their own encoding step. If your decoded output still contains %20-style sequences after clicking "Decode," run Decode again — you likely have double-encoded input, not a broken tool.
Unreserved vs. Reserved Characters
Per RFC 3986, only A-Z a-z 0-9 - _ . ~ are guaranteed never to be encoded (the "unreserved" set) — everything else is fair game for percent-encoding depending on context. Reserved characters like / ? # [ ] @ ! $ & ' ( ) * + , ; = have structural meaning somewhere in a URI, which is exactly why blindly encoding an entire URL (rather than just the values going into it) breaks it — the encoder can't tell the difference between a / that separates path segments and a literal slash you meant as data.
Component encoding example (correct use of this tool):
Value: hello world & special chars
Encoded: hello%20world%20%26%20special%20chars
URL Encoding Standards & Characters
Reserved Characters
:%3A - Scheme delimiter?%3F - Query string indicator&%26 - Parameter separator=%3D - Parameter value delimiter#%23 - Fragment identifier/%2F - Path separator
Commonly Encoded Characters
space%20 (or +)@%40 - At symbol!%21 - Exclamation*%2A - Asterisk'%27 - Single quote()%28 %29 - Parentheses
Technical Information
Our URL encoder implements the standard percent-encoding according to RFC 3986:
- Standard: RFC 3986 Uniform Resource Identifier (URI) specification
- Encoding Method: Unreserved characters (A-Z, a-z, 0-9, -, ., _, ~) are not encoded
- Reserved Characters: Special characters encoded as %HH where HH is hexadecimal ASCII value
- UTF-8 Support: Non-ASCII characters encoded using UTF-8 byte sequence
- Query String Format: Supports both space as %20 and + for backward compatibility
Understanding URL Structure
A complete URL consists of several components, each with specific encoding rules:
https://user:pass@example.com:8080/path?query=value#fragment
- Scheme: https:// (not encoded)
- Authority: user:pass@example.com:8080 (credentials and host)
- Path: /path (should be encoded carefully)
- Query: ?query=value (parameters must be encoded)
- Fragment: #fragment (hash/anchor identifier)
URL Encoding Best Practices
Frequently Asked Questions
I encoded a full URL and now the slashes and colons are gone — is that a bug?
No — this tool uses encodeURIComponent(), which escapes every reserved character including / : ? & =. That's correct behavior for encoding a single value, but it means you should only feed it the part of the URL you're inserting (a parameter value), not the whole URL with its structure intact.
Why does my decoded text still have %20 or %26 in it?
The input was probably encoded twice before you got it (common when a URL passes through a redirect, a proxy, and a client router, each encoding independently). Run "Decode" again on the result — double-decoding double-encoded text resolves it.
Should I encode the entire URL or just specific parts?
Encode only the data you're inserting into a URL — a query parameter's value, a form field, a path segment you're constructing dynamically. Leave the scheme, host, and structural slashes/punctuation of the URL itself alone; encoding them breaks the URL's structure rather than protecting it.
Why is a space sometimes %20 and sometimes a plus sign?
%20 is the RFC 3986 percent-encoding this tool produces. The + convention comes from the older application/x-www-form-urlencoded format used in classic HTML form submissions — it's a different, narrower spec, and a literal + in a query string can actually mean "space" there but mean a literal plus sign elsewhere, which is itself a source of real bugs when mixing libraries that disagree.
Can I use this to protect sensitive data in a URL?
No. Percent-encoding is a reversible transformation for safe transmission, not encryption or obfuscation — anyone can decode it instantly. Never rely on URL encoding to hide passwords, tokens, or personal data from anyone who might see the URL.