PK Systems
Encoders & decoders

URL Encoder / Decoder

Percent-encode and decode URLs and query parameters. Component or full-URL scope, runs entirely in your browser.

URL Encoder / Decoder

Component encodes everything that's not URL-safe (uses encodeURIComponent). Full URL keeps :/?&=# unencoded so a whole URL stays valid (uses encodeURI).

Output

What is URL encoding?

URL encoding (also called percent-encoding) is a way of representing characters that aren't safe in a URL — spaces, accented letters, &, ?, #, and so on — by replacing them with % followed by their hexadecimal byte value. The standard is defined in RFC 3986. For non-ASCII characters, the bytes come from the UTF-8 encoding, so é becomes %C3%A9 (two bytes). This tool wraps the browser's built-in encodeURIComponent and decodeURIComponent functions.

How to use this encoder

Pick Encode or Decode in the mode toggle, then choose the scope. Component is the right default for query-string values, form fields, and anything you're going to drop into ?key=…. Full URL is for whole URLs you want to escape minimally — it leaves : / ? & = # alone so the structural characters keep their meaning. Paste your text and the result updates live. Use Swap to move the output back into the input and flip the mode for a quick round-trip.

Component vs Full URL — which to pick?

If you're encoding a single value (a search term, a redirect target, an email address) and pasting it into a query string, use Component. If you're encoding a complete URL that's already roughly valid and you only want to escape the unsafe bits, use Full URL. The two behave very differently on characters like ? and & — Component encodes them, Full URL doesn't. When in doubt, encode the values inside a URL with Component, then assemble the URL yourself.

Common percent-encodings

Character Encoded Notes
space%20Spaces become %20 in URLs (or + in form-encoded bodies).
&%26Separates query-string parameters; must be encoded inside a value.
=%3DSeparates a query parameter's name from its value.
?%3FMarks the start of the query string.
#%23Marks the start of the URL fragment (anchor).
/%2FPath separator; encoded only inside path segments.
é%C3%A9Non-ASCII characters are UTF-8 encoded then percent-escaped byte-by-byte.

Frequently asked questions

Is anything sent to a server?
No. Encoding and decoding both run in your browser via the built-in encodeURIComponent / decodeURIComponent APIs. Nothing is logged or transmitted. You can confirm by opening DevTools > Network — no requests fire while you type.
Why does + sometimes mean a space?
Because of a different (older) encoding called application/x-www-form-urlencoded, used in HTML form submissions. There, spaces become + instead of %20. RFC 3986 percent-encoding (what this tool uses) always uses %20. If you're decoding the body of a form submission and see + in place of spaces, replace them with spaces before decoding, or use a dedicated form-decoder.
Why does decoding fail with an error?
decodeURIComponent throws a URIError if the input contains a stray % that isn't followed by two valid hex digits, or if the resulting bytes aren't valid UTF-8. Common culprits are double-encoded strings (run decode twice) or copy-pasted URLs that got mangled by an editor's auto-correct.
What's the difference between encodeURI and encodeURIComponent?
encodeURI is intended for whole URLs — it leaves : / ? & = # @ and + alone, because those characters carry structural meaning in a URL. encodeURIComponent is for individual pieces of a URL (a query value, a path segment) and encodes everything that isn't unreserved. As a rule of thumb: build a URL by string-concatenating encodeURIComponent'd parts; never trust encodeURI for user input.
Can I encode emoji?
Yes. The browser converts the emoji to its UTF-8 byte sequence, then percent-encodes each byte. A single emoji like 🎉 turns into four percent-escapes (%F0%9F%8E%89) because it's a 4-byte UTF-8 codepoint outside the basic plane. Decoding reverses the process — the result is the original emoji.
Should I encode the URL more than once?
Only if you're nesting URLs inside URLs (a redirect parameter pointing at another URL). Each level of nesting needs one extra encoding pass — otherwise the inner URL's ? and & get parsed as part of the outer URL. To decode such a value, run decode the same number of times. If you accidentally double-encoded a single URL, decode it twice and you'll get back the original.