Encode text for a URL parameter or decode percent escapes into readable text. The tool applies native encodeURIComponent or decodeURIComponent to the entire input, treating it as component data rather than preserving a complete URL's structure.
Runs locally in your browserPaste text directly. Conversion runs in the browser without requesting the entered address; there is no file input or batch mode.
Encoding leaves A-Z a-z 0-9 and - _ . ! ~ * ' ( ) unchanged. Other valid Unicode characters use UTF-8 percent escapes: 你好 😀 becomes %E4%BD%A0%E5%A5%BD%20%F0%9F%98%80. There is no extra RFC 3986 escaping of ! ' ( ) *.
a=1&b=two words becomes a%3D1%26b%3Dtwo%20words. A complete URL also has its : / ? & = encoded, so use this when the whole string is data, not when its URL structure must remain usable.
Decoded separators can change URL interpretation when reinserted. Handle the result as parameter data as appropriate; this is neither a URL validator nor encryption. Output is text, not executed HTML.
Encoding %20 produces %2520. Decoding %2520 yields the literal text %20, not a space. The tool does not automatically decode again or replace the input.
This is not application/x-www-form-urlencoded processing. Encoding maps a space to %20 and + to %2B. Decoding leaves a literal + alone: a+b%20c becomes a+b c.
Decoding rejects malformed escapes such as %, %GG or %E4%A and invalid UTF-8 such as %FF or %C0%AF, without replacement characters. Encoding an unpaired UTF-16 surrogate also fails. Decoding leaves non-escaped literal text unchanged; it does not validate every character.
Whitespace is not trimmed, including at either end. However, the browser's textarea normalizes entered line endings to LF, which encodes as %0A; original CRLF or CR bytes are not preserved. No Unicode normalization is added. Empty input gives an empty result.