URL Encoder and Decoder
Encode and decode URLs and query strings, with both encodeURIComponent and encodeURI, a batch mode for many lines and a query parameter table.
Two mistakes account for most broken integrations: escaping & and = together with the values while building a query string, so the backend sees one parameter instead of two; and comparing a signature that no longer matches because a decoded value contains a + where the original had a space. The encoding rules themselves are short - the difficulty is knowing which mode a given context calls for and what a plus sign is supposed to mean.
The tool calls the browser's native encodeURIComponent, encodeURI and decodeURIComponent, and keeps every input inside the page. Batch mode handles logs, config files and lists of links one line at a time, and the query string parser breaks a=1&b=2 or a full URL into a table, so a misspelled parameter name or a duplicated key becomes visible immediately.
encodeURIComponent and encodeURI are not interchangeable
encodeURI leaves the reserved characters : / ? # [ ] @ ! $ & ' ( ) * + , ; = untouched, which is what you want when escaping a complete URL without destroying its structure. encodeURIComponent escapes all of them, which is what a single parameter name or value needs. Using encodeURI on a value lets an embedded & or = be read as a separator and splits one parameter into two; using encodeURIComponent to assemble a whole link escapes the slashes in the scheme and path and produces a URL that no longer resolves. Match the function to the unit you are escaping, not to the size of the string.
Plus signs, spaces and decoding ambiguity
In application/x-www-form-urlencoded - the format a form submission uses - + stands for a space, so a space may legitimately be written either as + or as %20. In the path portion of a URL, + is simply a plus sign. decodeURIComponent only resolves percent escapes and leaves + alone, which is why decoded form data often comes back with plus signs where the spaces used to be. The toggle in this tool restores + to a space, so you can pick the convention the data was written with instead of guessing.
Why a non-ASCII URL becomes three times as long
Only ASCII characters may appear in a URL, so anything else is first turned into UTF-8 bytes and then written in percent form. A CJK character occupies 3 bytes there, each byte becomes three characters such as %E4%B8%AD, and one character therefore costs 9 characters of URL; an emoji outside the Basic Multilingual Plane takes 4 bytes and 12 characters. Older systems built on GBK or Shift_JIS produce two-byte escapes that decode to mojibake when the other side assumes UTF-8 - a mismatch worth checking before blaming the client. The same rule applies to the +, / and = that Base64 and JWTs carry: they must be percent-encoded before they enter a query string.
Frequently asked questions
- What is the difference between URL encoding and URL decoding?
- Encoding rewrites characters that cannot appear in a URL - spaces, non-ASCII text, # and & - as percent escapes; decoding turns %E4%B8%AD and the like back into the original characters. Browsers show the decoded form in the address bar, so be careful not to decode an already-decoded string twice when moving a link into code.
- Why did my spaces turn into plus signs after decoding?
- Either the space was encoded as + in the first place, following the form convention, in which case you have to replace + with a space yourself; or the original genuinely contained a plus, which is a legal character in a path and is never escaped. Decide whether the data came from a form or a path, then apply the matching convention.
- Should I use encodeURIComponent or encodeURI?
- encodeURIComponent for a single parameter name or value, because it also escapes & = ? / # and cannot break the structure you are assembling. encodeURI for a complete URL when you only want spaces and non-ASCII characters escaped. Applying encodeURIComponent to a whole URL escapes the scheme and path slashes and the link stops working.
- Why does a non-ASCII URL end up three times longer?
- UTF-8 spends 3 bytes on a common CJK character, and each byte is written as %XX, so one character becomes nine characters of URL. Search engines and most servers expect UTF-8; escapes produced by a legacy encoding such as GBK or Shift_JIS decode to garbage and are a frequent source of apparently random corruption.