URL encode and decode

How to use

1. Choose Encode and type the text. Four results appear, one per method. Copy the one that fits: encodeURIComponent for a query value or path segment, encodeURI for a complete URL, form encoding for an HTML form body or a ?key=value query built the way browsers build it.
2. Choose Decode and paste percent-encoded text, a path or a whole query string. Both readings are shown: as a URL component (+ stays +) and as form data (+ becomes a space). If they differ, use the one that matches where the text came from.
3. Read the Double-encoding check. It decodes up to five times and lists each step. A result of 2 or more layers with %25XX in the text usually means something encoded already-encoded text.
4. If the input looks like a query string (a=1&b=2), a table splits it into parameters using the WHATWG parser rules, which is how a browser's URLSearchParams reads it.
5. If decoding fails, the message names the position of the bad % or the invalid UTF-8 byte. Use result as input chains a decode after an encode, which is a quick way to test a round trip.

Worked examples

Every row below comes from a data file that a unit test runs through the tool and, separately, through the browser's own encodeURIComponent, encodeURI and URLSearchParams. The expected strings were first worked out by hand from the byte values.

A space and a plus

Input: Tom & Jerry + friends

Non-ASCII text

Input: café €5

The characters ! ' ( ) * ~

Input: wow!(it's*great~)

A whole URL placed inside a query parameter

Input: https://a.example/p?q=1&r=2

RFC 3986 reserved characters and what each encoder does

RFC 3986 section 2.2 splits the characters into gen-delims (: / ? # [ ] @) and sub-delims (! $ & ' ( ) * + , ; =), and section 2.3 defines unreserved characters as letters, digits and - . _ ~. A reserved character used as data must be encoded or it can change what the URL means. The table is generated by the same code as the tool, and a test checks the class counts (7 gen-delims, 11 sub-delims).

"kept" means the character is written as-is. Characters above U+007F are always written as the percent-escaped bytes of their UTF-8 form by all four encoders.

What goes wrong

Each case is a real input with the exact output of the tool (messages quoted verbatim).

A literal percent sign: "100%"

Input: 100%

Error: The "%" at position 4 is not followed by two hexadecimal digits (the text ends after "%").

decodeURIComponent("100%") throws URIError: URI malformed. The fix is to encode the percent sign as %25 when the text is produced.

A percent sign before letters: "50%off"

Input: 50%off

Error: The "%" at position 3 is followed by "of", which is not two hexadecimal digits.

"%of" is not an escape because "o" is not a hex digit. Native decodeURIComponent throws; the WHATWG form parser would keep "50%off" unchanged.

A Latin-1 escape in a UTF-8 world: "caf%E9"

Input: caf%E9

Error: The escape sequences starting at position 4 do not form valid UTF-8: the data ends inside a 3-byte sequence that starts with 0xE9.

E9 is é in Latin-1 but, in UTF-8, a lead byte that needs two more bytes. Old systems produced such links. No generic decoder can know the intended charset.

Encoded twice: "caf%25C3%25A9"

Input: caf%25C3%25A9

After the first decode: caf%C3%A9

One decode gives "caf%C3%A9" (what the page shows is still escaped); a second gives "café". The detector reports 2 layers.

A plus that means different things

Input: a+b%2Bc

Readings: URL rule: "a+b+c" Form rule: "a b+c"

In a path, + is a literal plus (RFC 3986 gives it no special meaning as data). In a query read as application/x-www-form-urlencoded it is a space. The same text, two answers.

encodeURI on a value

Input: a&b=c

encodeURI output: a&b=c

encodeURI("a&b=c") returns it unchanged, so the receiving server splits it into two parameters. encodeURIComponent gives "a%26b%3Dc".

Limits & gotchas

• Everything is UTF-8. The tool encodes text as UTF-8 and decodes assuming UTF-8, as RFC 3986 section 2.5 recommends for new URI schemes and as the WHATWG URL Standard requires. It does not decode other charsets such as Latin-1 or Shift_JIS. If an old system sends %E9 for é, the decoder reports invalid UTF-8 instead of guessing.
• This is text-level encoding, not URL parsing. The tool does not split a URL into scheme, host, path and query and encode each part with its own rules. The WHATWG URL Standard uses different percent-encode sets for the path, query, fragment and userinfo (for example the path set also encodes ?, ^, `, { and }), and hosts use IDNA/punycode instead of percent-encoding. For a whole URL, paste it into your own code's URL class.
• Lone surrogates. A string containing half of a surrogate pair cannot be written as UTF-8. Native encodeURIComponent throws URIError; URLSearchParams silently substitutes U+FFFD. This tool stops and tells you which character.
• Strict decoding versus the browser form parser. The decode result shown above is strict, like decodeURIComponent: a bad % is an error. The WHATWG form parser instead keeps a bad % as a literal and replaces invalid UTF-8 with U+FFFD. The query table uses the lenient parser, so it can show values that the strict panel rejects.
• The double-encoding check is a heuristic. It counts how often the text can be decoded in a row. It cannot know your intent: a tutorial that shows %2520 as an example is "double-encoded" on purpose.
• Case of hex digits. Output uses uppercase (%C3), as RFC 3986 section 2.1 recommends. Lowercase input decodes fine and is equivalent.
• The share link carries your text after #, up to about 3,000 characters. Do not share links that contain tokens, passwords or private URLs.

FAQ

Sources

• IETF: RFC 3986: Uniform Resource Identifier (URI): Generic Syntax Used for: Section 2.1 percent-encoding, 2.2 reserved characters (gen-delims and sub-delims), 2.3 unreserved characters, 2.4 when to encode and decode, 2.5 UTF-8 for new schemes, 3.4 query, 6.2.2.2 normalising percent-encoding.
• WHATWG: URL Standard: percent-encode sets and application/x-www-form-urlencoded Used for: The component, path, query and application/x-www-form-urlencoded percent-encode sets; the form serializer (space to +, UTF-8) and parser (+ to space, then percent-decode).
• Ecma International: ECMAScript Language Specification: URI Handling Functions (encodeURI, encodeURIComponent, decodeURI, decodeURIComponent) Used for: Which characters encodeURI and encodeURIComponent leave alone, and that lone surrogates throw URIError.
• IETF: RFC 3629: UTF-8, a transformation format of ISO 10646 Used for: Valid UTF-8 byte sequences: lead bytes, continuation bytes, overlong forms, surrogates and U+10FFFF are not allowed.

Every document above was opened and read on 2026-10-02. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

Related tools

• Base64 encode and decode

  Text or files, standard or URL-safe alphabet, padding, MIME line wrapping, and exact reasons when input is invalid.

• JWT decoder

  Read a token’s header, claims and dates locally. Decoding is not verification; optional HMAC check with your own secret.

• JSON ↔ YAML converter

  Convert both ways and see where YAML quietly changes your data types.