A value with a slash
encodeURI leaves the slash, so the value adds a path segment; encodeURIComponent escapes it
a/b?c=d&e
URL Encoder and Decoder
Encode or decode a URL, with encodeURI, encodeURIComponent and the strict RFC 3986 form side by side. Which one you want depends on whether you are encoding a whole URL or a single value, and the wrong choice turns one query parameter into two.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Encoded twice
Escapes survive one decode, which means a value was encoded by the app and again by the client
a%2520b
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Using encodeURI on a query parameter value
encodeURI preserves & and / so the URL keeps its structure. A value containing either therefore ADDS structure: one parameter becomes two, or a path segment appears. Nothing errors and the request succeeds meaning something else.
Instead:encodeURIComponent for any single value. encodeURI only for a whole URL you assembled yourself.
Assuming encodeURIComponent is RFC 3986 compliant
It leaves ! ' ( ) * unescaped. That is fine until a receiver canonicalises the URL or a signature is computed over it, and AWS SigV4 and OAuth 1.0 both do. The failure reports a credentials error, not an encoding one.
Instead:Escape those five yourself when signing. The strict form on this page shows the result.
Expecting decodeURIComponent to turn + into a space
It does not. Plus means space only in form-encoded bodies; in a path or fragment it is a literal plus. So the same string decodes differently depending on where it came from.
Instead:Encode space as %20 and a literal plus as %2B. Both are unambiguous everywhere.
encodeURI and encodeURIComponent differ on exactly the characters that matter
Both escape a string for a URL. They disagree about the delimiters that give a URL its structure, and that disagreement is the entire reason there are two of them.
Which one you want
encodeURI is for a COMPLETE URL and deliberately preserves : / ? # & = so the URL keeps working. encodeURIComponent is for ONE value and escapes them, because a value must not be able to add structure. If you are encoding a query parameter, a path segment, or anything a user supplied, it is encodeURIComponent, and that is the answer far more often than not.
The failure this causes
Encode a value containing an ampersand with encodeURI and it stays an ampersand, so a=x&y arrives as two parameters instead of one. A value containing a slash stays a slash, so it adds a path segment. Neither errors. The request succeeds and means something different from what you sent, which is why this survives testing.
Neither is strictly RFC 3986 compliant
Both leave the five characters ! ' ( ) * unescaped, and RFC 3986 reserves them. The gap is small and it matters in exactly two places: a receiver that canonicalises the URL, and a signature computed over it. AWS SigV4 and OAuth 1.0 both care, and a signature that fails for this reason reports a credentials error rather than an encoding one. The strict form is shown for that case.
Plus is a space in a form body and a plus everywhere else
Form encoding writes space as +. RFC 3986 does not: in a path or a fragment, + is a literal plus. So the same string decodes differently depending on where it appears, and decodeURIComponent does NOT turn + into a space, which surprises people who have only seen it in query strings. Use %20 for space and %2B for a literal plus and the ambiguity is gone.
Double encoding
A value encoded by application code and then again by an HTTP client arrives with visible percent signs after one decode. The receiver then fails a format check, so the error names the field rather than the encoding. This tool reports it when one decode leaves escapes behind.
What this cannot see
Where the value is going, which is what decides which form is correct. It shows all three and names the trade-off. It also cannot know your receiver's strictness: some accept a bare percent sign, some reject the whole URL. Everything runs in your browser and nothing is uploaded, which matters when the URL carries a token.
More encoding tools
Base64 Encoder & Decoder Both directions, UTF-8 done right Unix Timestamp Converter Seconds or milliseconds? It says which JWT Decoder & Inspector Read the claims, and what is wrong with them HTML Entity Encoder and Decoder Five characters, not four hundred Hex Encoder and Decoder Bytes, with a hex dump Base32 Encoder and Decoder Two alphabets that decode differently String Escape Converter Six targets, one of them injection Punycode and IDN Converter The domain that is not what it looks like