URL Encoder & Decoder

How to use the URL encoder

1. Choose a direction — encode or decode.
2. Choose the escape set. This is the important step, and the explanation under each option says what it is for.
3. Paste your input. Conversion happens as you type.
4. Copy the result, or swap it back through in the other direction to check it round-trips.

Nothing is uploaded. Both directions use the browser's own built-in functions, on your device.

When you would need this

Building a link with a search term in it. Anything a user typed needs escaping before it goes into a query string, or a & in their input silently truncates your URL.

Reading a redirect chain. OAuth flows and tracking links nest encoded URLs inside other URLs, sometimes several deep. Decoding shows where you would actually end up.

Debugging an API request. A parameter that arrives wrong at the server is very often an encoding problem rather than a logic one.

Inspecting a suspicious link. Decoding a heavily-encoded URL before clicking shows the real destination.

Constructing a form submission by hand. Testing an endpoint with curl means encoding the body the way a browser would.

The mistake that breaks most encoded links

There is one error behind the majority of URL encoding problems, and it comes from reaching for the wrong function by default.

encodeURIComponent is the one most people know, and it escapes aggressively — including :, /, ?, #, & and =. That is exactly right for a value you are inserting into a URL, because those characters would otherwise be read as structure. Encode the search term cats & dogs and you get cats%20%26%20dogs, so the & becomes part of your value instead of starting a new parameter.

Apply the same function to a whole URL and you destroy it:

https://example.com/page?q=1
→ https%3A%2F%2Fexample.com%2Fpage%3Fq%3D1

Every character that made it a URL is now an escape sequence. It is a valid string, and it is no longer an address. Browsers treat it as a relative path or hand it to a search engine.

The rule is simple once stated: escape the parts, not the whole. Build your URL from an unescaped structure with escaped values inserted into it. If you already have a finished URL and only need it to survive transmission, use whole-URL encoding, which leaves the structure alone.

Why an accent becomes two escapes

Percent-encoding operates on bytes, not characters. Non-ASCII characters are first converted to UTF-8, then each byte is escaped separately.

So café becomes caf%C3%A9 — the é is two bytes in UTF-8, C3 and A9, and each gets its own escape. A Chinese character typically takes three bytes and produces three escapes; an emoji takes four.

This is why encoded URLs containing non-English text look so much longer than the original, and why counting characters in an encoded URL tells you very little about the text it represents.

It also explains a class of bug worth knowing: if a system decodes with the wrong assumed encoding, café comes back as café. That mangling — a single accented character becoming two odd ones — is the signature of a UTF-8 string being read as Latin-1 somewhere in the chain.

Encoding is not security

Percent-encoding is reversible with no key, exactly like Base64. It hides nothing.

It is worth knowing the reverse case though: encoding is sometimes used against you. A phishing link may percent-encode parts of a hostname or path so the destination is less obvious in a preview, or so a naive filter fails to match a blocklist. Decoding a suspicious link before clicking is a genuinely useful habit, and it is one of the more practical uses of a tool like this.

Limits and requirements

Decoding rejects malformed escapes. A % must be followed by two hexadecimal digits. Anything else reports an error rather than throwing or silently producing wrong output.

The + convention is query-string only. Form-data mode converts + back to a space when decoding. In a path segment, a + is a literal plus sign — decoding a path with form-data mode will corrupt it.

Double-encoded input needs two passes. %2520 is an encoded %20, which is itself an encoded space. Decoding once gives %20; decode again for the space. The swap button makes this quick.

Very long URLs. There is no limit here, but practical limits exist elsewhere — many servers reject URLs beyond about 8,000 characters, and some older software stops at 2,048.

Browser support. Any modern browser on desktop or mobile.

Privacy: how this tool handles your URLs

Encoding and decoding run in your browser using its own built-in functions. Nothing is transmitted, logged or stored.

URLs deserve more care than they usually get, because they carry more than an address. Password reset links contain single-use tokens that grant account access. OAuth callbacks carry authorisation codes. Plenty of APIs still accept keys as query parameters despite that being poor practice. Internal URLs reveal hostnames, service names and directory structures that describe how a system is built.

All of that ends up pasted into URL encoders routinely, and a server-side tool receives every character of it — where request URLs and bodies are logged by default at several layers.

You can verify the difference. Open your browser's developer tools, switch to the Network tab, and encode something: nothing carries your input. Or disconnect from the internet after the page loads and keep using it.