Why does "URL encode" give a different answer here than in JavaScript?

It doesn't — by default this tool uses encodeURIComponent semantics, the most common reading. But "URL encode" actually has four different correct answers depending on context (a query value, a whole URL, a form body, or strict RFC 3986), and every one of them escapes a slightly different set of characters. This tool shows which one produced your result.

Why did decoding fail on my input?

A percent-escape is malformed — a lone %, a truncated %2, or non-hex digits after %. The error names the exact position so you can find it. If the escape itself is fine but the decoded bytes aren't valid UTF-8, that's reported separately, because those are two different problems.

Is %FF really an error?

Not always. %FF isn't valid UTF-8, but it's a perfectly good character in windows-1252 (ÿ) — exactly what an older form might have sent. This tool tells you that instead of just failing.

Does this handle Unicode text correctly?

Yes — encoding and decoding both go through UTF-8 by default, so emoji, accented characters and non-Latin scripts round-trip correctly. Legacy single-byte charsets are also supported for both directions.

This tool runs entirely in your browser. Nothing you paste is uploaded.

How you can check →

URL Encoder / Decoder

Encoding & Decoding

Encode text for a URL, or decode it back — with the four different correct encodings, not just one, and proof that the result actually round-trips.

Text 0 characters

Encoded

0 characters

Encoding options

Encode as

Charset

See every character's result in all four modes at once in the percent-encoding table.

Code

“URL encode” has four correct answers

Most tools present URL encoding as a single operation, but the platform itself disagrees with itself: encodeURI, encodeURIComponent, form encoding (URLSearchParams) and strict RFC 3986 escape a different set of characters. For example, encodeURIComponent leaves !, ', (, ) and * unescaped, while strict RFC 3986 escapes all five. Those five characters are exactly why MDN documents a workaround, and it's the reason a signature scheme like OAuth 1.0 or AWS SigV4 — which require strict RFC 3986 — rejects the output of a naive encodeURIComponent call. This tool defaults to encodeURIComponent semantics because that's what most people mean, and names the mode in the receipt so you always know which one you got.

Why a literal `+` is sometimes a space

In a query string or a form body (application/x-www-form-urlencoded), + means a space. Everywhere else in a URI, + is a literal plus sign. Decoding the wrong way corrupts real data: base64 output contains +, so a base64 value passed through a query string and decoded with the wrong reading comes back with spaces where + characters used to be — and the failure shows up somewhere downstream, far from the actual cause.

Why `%FF` isn’t always an error

JavaScript's decodeURIComponent throws the same opaque URIError: URI malformed whether the problem is a truncated escape, invalid hex digits, or a byte sequence that just isn't valid UTF-8. %FF triggers that error too — but %FF is a perfectly valid character (ÿ) in windows-1252, exactly what a legacy form submission would send. This tool decodes in two separate steps — percent-decode to bytes, then charset-decode those bytes — so it can tell you which half actually failed, and offer the matching charset as a one-click fix.

Common use cases

Encoding a value before appending it to a query string
Decoding a query parameter or form field pasted from a log line or a browser's network tab
Checking whether an API's percent-encoding matches the RFC 3986 a signature scheme requires
Confirming a base64 or JWT value survived a trip through a URL unchanged

Want the full character-by-character breakdown across all four modes? See the percent-encoding table. Splitting a whole URL into its parts instead? Use the URL parser.

Frequently asked questions

Why does "URL encode" give a different answer here than in JavaScript?: It doesn't — by default this tool uses encodeURIComponent semantics, the most common reading. But "URL encode" actually has four different correct answers depending on context (a query value, a whole URL, a form body, or strict RFC 3986), and every one of them escapes a slightly different set of characters. This tool shows which one produced your result.
Why did decoding fail on my input?: A percent-escape is malformed — a lone %, a truncated %2, or non-hex digits after %. The error names the exact position so you can find it. If the escape itself is fine but the decoded bytes aren't valid UTF-8, that's reported separately, because those are two different problems.
Is %FF really an error?: Not always. %FF isn't valid UTF-8, but it's a perfectly good character in windows-1252 (ÿ) — exactly what an older form might have sent. This tool tells you that instead of just failing.
Does this handle Unicode text correctly?: Yes — encoding and decoding both go through UTF-8 by default, so emoji, accented characters and non-Latin scripts round-trip correctly. Legacy single-byte charsets are also supported for both directions.

HMAC Generator

HMAC-sign or verify a message, with real key-encoding support and the actual Stripe, GitHub, Slack and Shopify signing schemes — not just HMAC(secret, body).

URL Parser

Split a URL into its parts, decode every query parameter, and rebuild it.

Base64 Encoder/Decoder

Encode text to base64 or decode base64 back to text.