Why is my space %20 and not a plus sign?

Because those belong to two different rules. Percent-encoding, which a URL path and a modern query string use, writes a space as `%20`. The plus sign belongs to form encoding, which is what an HTML form submits.

My decoded text still has plus signs. Is that a bug?

No, but it is the thing to watch. This tool follows percent-encoding, where `+` is a literal plus. If your input came from a form or an old query string, the plus means a space there — replace `+` with `%20` before decoding.

Why did my slash and ampersand get escaped?

Because the tool encodes a **value**, not a whole URL. A slash inside a value would look like a path separator, an ampersand like the start of the next parameter. Escaping them is what keeps the value one value.

URL Encode — A Value That Survives the Trip

Percent-encode text for a URL: space becomes %20 and every reserved character is escaped, so the value reaches the server as you wrote it.

Instant Private Zero cookies

What this tool does

The text becomes UTF-8 bytes, and every byte outside the unreserved set is written as a percent sign followed by two hexadecimal digits. What survives untouched is letters, digits, and - . _ ~.

Everything else is escaped, including the characters that structure a URL:

a b        →  a%20b
a+b&c=d    →  a%2Bb%26c%3Dd
café       →  caf%C3%A9
😀         →  %F0%9F%98%80

Percent-encoding, not form encoding

This is the distinction worth carrying away, because it silently corrupts data in both directions.

Percent-encoding is what a URL path and a modern query string use. A space is %20. A plus sign is a literal plus, and is itself escaped to %2B when it appears in a value.

Form encoding — application/x-www-form-urlencoded, what an HTML form submits — writes a space as + instead. It is the older convention, and it is still everywhere.

This tool applies the first rule, matching what encodeURIComponent and decodeURIComponent do in a browser.

The consequence when decoding

A string that came from a form, or from a query string written in the form style, will keep its plus signs here rather than turning them back into spaces. a+b decodes to a+b.

That is correct for percent-encoding and wrong for what you probably wanted. If the input came from a form, replace + with %20 before decoding, or use a form-decoder.

A lone percent sign that is not followed by two hexadecimal digits is an error rather than a guess — 100% cannot be decoded, and pretending otherwise would invent a byte.

It encodes a value, not a URL

Give it a whole URL and it will escape the :// and the separators too, which is not what you want. Encode each value separately, then assemble the URL around them.

Private by design

Everything runs locally in your browser with JavaScript. Your data is never uploaded, which makes the tool safe for sensitive content, and it keeps working offline.

Frequently asked questions

Why is my space %20 and not a plus sign?: Because those belong to two different rules. Percent-encoding, which a URL path and a modern query string use, writes a space as `%20`. The plus sign belongs to form encoding, which is what an HTML form submits.
My decoded text still has plus signs. Is that a bug?: No, but it is the thing to watch. This tool follows percent-encoding, where `+` is a literal plus. If your input came from a form or an old query string, the plus means a space there — replace `+` with `%20` before decoding.
Why did my slash and ampersand get escaped?: Because the tool encodes a **value**, not a whole URL. A slash inside a value would look like a path separator, an ampersand like the start of the next parameter. Escaping them is what keeps the value one value.