URL Encoder Decoder
Percent-encode or decode a URL component, a complete URL-shaped string, or one form value without mixing their different delimiter rules.
Choose this for data that belongs inside one URL component, such as a query value or path segment.
Output
Encoded or decoded output will appear here...
Percent-encoding does not hide a value
The transformation happens in the browser with JavaScript's URI APIs and URLSearchParams. Nothing here encrypts a token, password, path, or query value. Treat encoded secrets exactly like the original secret, and validate decoded data for the place where it will actually be used.
Encode the data before it becomes a delimiter
A URL is made from components, and several characters have structural jobs inside those components. An ampersand can separate query fields, a slash can separate path segments, and a question mark can begin a query. When one of those characters is ordinary data instead, it may need to be percent-encoded before the final URL is assembled.
Percent-encoding writes a byte as %HH. For text outside ASCII, modern web APIs first encode the characters as UTF-8 and then percent-encode the resulting bytes. That is why प becomes several %HH sequences rather than one escape.
The same text changes depending on where it belongs
| Input | Context | Result / reason |
|---|---|---|
tea & coffee | URL component | tea%20%26%20coffee — the ampersand is data, not a separator. |
https://example.com/a b?q=x | Complete URL-shaped string | The scheme and delimiters stay structural while the space is encoded. |
A+B C | Form value | A%2BB+C — literal plus is escaped and the space becomes +. |
A plus sign is only a space in form-style decoding
Generic URI percent-decoding does not turn + into a space. The plus-for-space convention belongs to application/x-www-form-urlencoded. That difference matters for search terms, signed parameters, identifiers, and any value where a literal plus sign carries meaning.
Form mode follows the browser's URLSearchParams behavior for one value. It is not a whole-query parser: repeated names, ordering, and blank fields are properties of the complete tuple list, not of a single value by itself.
Decode only after the URL has been separated into components
Decoding %2F to / or %3F to? too early can change the structure you thought you were inspecting. RFC 3986 explicitly recommends separating components before decoding percent-encoded octets that could become delimiters.
The same caution applies to repeated transformations. If %20is already an encoded space, another encoding pass turns it into%2520. That may be required by a nested protocol layer, but it should be deliberate rather than automatic.
Malformed percent escapes and malformed Unicode fail for different reasons
A percent escape needs two hexadecimal digits. Even when every escape is shaped correctly, decoding can still fail if the resulting byte sequence is not valid UTF-8. Encoding has a different failure mode: JavaScript URI functions reject an unpaired UTF-16 surrogate because it cannot be turned into a Unicode scalar value for UTF-8 encoding.
Those errors are left visible rather than repaired. Guessing at a missing byte or malformed character can produce a URL that looks plausible while identifying different data.
RFC 3986 and browser URLs describe different layers
RFC 3986 explains URI syntax, reserved characters, percent-encoding, and why the same string should not be blindly encoded or decoded more than once. The modern browser parsing model is defined by the WHATWG URL Standard, which also defines application/x-www-form-urlencoded and its plus-for-space behavior.
Complete URL mode intentionally uses JavaScript's encodeURI()and decodeURI(). It does not run the string through the WHATWG URL parser, so it will not normalize a hostname, default port, dot segments, or an internationalized domain name.
What a text transformation cannot decide
- Whether a complete URL exists, resolves, redirects, or is safe to visit.
- Whether a decoded value is authorized, trusted, or valid for an application.
- Whether an encoded slash should remain data or become a path separator.
- Whether double encoding is accidental or required by another serialization layer.
- Whether URL encoding is the right defense for HTML, SQL, shell, filesystem, or redirect handling.