URL Encoder/Decoder

Encode text for URLs with encodeURIComponent, or decode it back, with a space-as-plus option for old form data. Runs entirely in your browser.

Encoding happens locally in your browser. Nothing ever leaves your device.

—

How It Works

The tool mirrors what a browser does when it builds a request: Encode runs encodeURIComponent over your input, replacing every character that is not a URL-safe letter, digit or one of - _ . ~ with its UTF-8 bytes written as %XX. Decode reverses that, first turning + back into spaces (the form convention) and then resolving the percent sequences, and it flags an error when a % is not followed by two valid hex digits.

encodeURIComponent vs encodeURI
encodeURI assumes you are passing a complete URL and leaves the structural characters — : / ? # [ ] @ ! $ & ' ( ) * + , ; = — untouched. encodeURIComponent assumes you are encoding one component (a query value, a path segment) and escapes all of them too. For parameter values, encodeURIComponent is the safer choice, and it is what this tool uses.
Form encoding (application/x-www-form-urlencoded)
The way HTML forms submit query strings differs from pure percent encoding in one visible way: a space becomes + instead of %20. The "Space as +" checkbox reproduces that convention, and Decode always accepts + as a space, so you can round-trip anything a browser form produced.
Reserved vs unreserved characters
Only unreserved characters (letters, digits, - _ . ~) may appear literally. Reserved characters carry syntax in a URL, and anything outside ASCII must be percent-encoded through its UTF-8 bytes — that is why an emoji becomes a four-byte sequence like %F0%9F%98%80.

Frequently Asked Questions

Should I encode already-encoded text?

No — encoding twice produces double-encoding. The percent sign itself is escaped, so %20 becomes %2520 and %40 becomes %2540, which most servers then hand to your application literally. If your string already contains %XX sequences, run Decode first to normalize it, edit, then Encode once.

Do query parameters and path segments need different encoding?

Encode each parameter value with encodeURIComponent and you are always safe. Path segments tolerate a few more characters (: @ + $) by convention, but encodeURIComponent escapes those too — servers decode them back, so the over-encoding is harmless. Reserve encodeURI for whole URLs when you want the : / ? # structure preserved.

Why do & and = get encoded?

Because they are the delimiters of a query string: & separates parameters and = separates a name from its value. If your actual value contains one — for example a URL inside a parameter or a promo code like SALE&2026 — it must be escaped (%26, %3D) so the server does not split your value in the wrong place.

How are emoji and non-Latin text handled?

URLs can only carry ASCII, so everything else is encoded as its UTF-8 bytes, one %XX per byte. café becomes caf%C3%A9 and an emoji becomes four bytes like %F0%9F%98%80. This is the modern standard; the older %uXXXX form used by JavaScript's escape() is not valid in URLs and this tool does not produce it.

Is anything uploaded to a server?

No. Encoding and decoding are a few lines of vanilla JavaScript running in your browser. Your URLs never leave your device, and there is no account, no tracking and no network request attached to a conversion.