URL Encoder & Decoder (Free, No Upload)

URL encoding (percent-encoding) replaces characters a URL cannot safely carry with a % sign followed by two hex digits — the byte value of the character. A space becomes %20, an ampersand becomes %26, and the French é becomes %C3%A9 (its two UTF-8 bytes). It exists because URLs were designed for a tiny ASCII alphabet: anything outside it — spaces, accents, emoji, symbols with structural meaning — must be encoded so every server on the internet reads the URL the same way.

%20 is a space. The % starts a percent-encoded byte, and 20 (hex) is 32 in decimal — the ASCII code for a space. So "hello world" becomes "hello%20world". You will see the same pattern for other characters: %26 is &, %3F is ?, and %C3%A9 is é.

That is form encoding — application/x-www-form-urlencoded, the format browsers use when an HTML form is submitted with GET. In that format, and only that format, a space is written as +. It is correct in query strings handled as form data, but wrong in paths: /files/hello+world.txt is a file literally named with plus signs. This tool has a dedicated Form mode that produces +, and a "decode + as space" toggle for reading form-encoded data.

encodeURIComponent is for a single value going into a URL: it encodes everything except A–Z, a–z, 0–9 and - _ . ! ~ * ' ( ). encodeURI is for a whole, already well-formed URL: it additionally leaves ; / ? : @ & = + $ , # untouched so the URL's structure survives. The classic bug is calling encodeURI on a value that contains & — as MDN itself demonstrates, encodeURI("https://example.com/?choice=Ben & Jerry's") keeps the &, so the query parses as two parameters. Rule of thumb: whole URL → encodeURI; each value you insert → encodeURIComponent.

Always encode: spaces, %, " < > \ ^ ` { | }, control characters, and every non-ASCII character (encoded as its UTF-8 bytes). In query values, also encode &, = and + because form/query conventions give them structural meaning — a literal + in a form query decodes as a space. The strict RFC 3986 set also encodes ! ' ( ) *, which JavaScript's built-ins leave as-is.

In JavaScript: encodeURIComponent(str) for a value, encodeURI(str) for a whole URL. For strict RFC 3986 add .replace(/[!"'()*]/g, c => "%" + c.charCodeAt(0).toString(16).toUpperCase()). In Python: urllib.parse.quote(text, safe="") is close to strict RFC 3986; quote_plus(text) produces form encoding (+ for spaces); quote(text, safe="!~*'()") approximates encodeURIComponent. In PHP: urlencode() = form encoding, rawurlencode() ≈ strict. The tool above has a "Do it in code" panel that generates these snippets for your exact input.

No. Base64 recodes every byte into a 64-character alphabet, making output ~33% larger and unreadable, and standard Base64 itself needs URL escaping. Percent-encoding only escapes the characters a URL cannot carry and leaves everything else readable — "caf%C3%A9" still clearly says café. They solve different problems; if you need Base64, use our Base64 converter.

Because no built-in JavaScript decoder converts + to a space — not decodeURIComponent, not decodeURI, not even the deprecated unescape. The correct form decoding is to replace + with a space first, then percent-decode: decodeURIComponent(s.replace(/\+/g, " ")). The order matters: a genuine %2B must survive as +. This tool has a "Decode + as space" checkbox that does the replacement correctly; it defaults on in the query parser and off elsewhere.

Use + only in form-encoded query data — the format HTML forms submit and most servers expect in ?key=value pairs. Use %20 everywhere else: paths, fragments, slugs, and any value handled as a single opaque string. Many servers read both, which is why the confusion survives — but in a path, + is a literal plus, so %20 is the safe universal choice.

No. Encoding and decoding happen entirely in your browser using built-in JavaScript APIs — you can verify this in the Network tab, or disconnect from the internet and the tool still works. This matters because URLs routinely carry tokens, API keys and session IDs: popular tools like urlencoder.org process your input on their servers by default. Nothing you paste here ever leaves your device.