URL Encoder & Decoder

Percent-encode text for a URL or decode it back, choosing between a single component, a whole URL, and form data where a space is a plus.

Enable JavaScript to customise; default output below.

Encoding reads the text as UTF-8, which is what every byte after a % represents.

Direction
Scope

Component encodes everything unsafe. Full URL keeps the structure. Form data turns a space into a plus.

More options Show
Live preview encoded.txt
search%3Fq%3Dcoffee%20%26%20cake

Output is valid and updates as you type.

Percent-encode text for a URL, or decode it back. Pick the scope that matches where the value is going: one parameter, a whole URL, or a form body.

How to use

  1. Use “component” for a single value, such as a query parameter or a path segment. It encodes everything that has meaning in a URL, including &, =, ? and /.
  2. Use “full URL” when the input is already a URL and you only want the unsafe characters fixed. It leaves the structure alone.
  3. Use “form data” for a application/x-www-form-urlencoded body, where a space is + rather than %20.
  4. Turn on the strict option when the value goes somewhere old or fussy: !, ', (, ) and * are reserved in RFC 3986 but left alone by the browser’s own function.
  5. Decoding uses the same scope, so form data decodes + back to a space.

Example

The same string in each scope:

Input:      https://example.com/a b?q=1&r=2
Component:  https%3A%2F%2Fexample.com%2Fa%20b%3Fq%3D1%26r%3D2
Full URL:   https://example.com/a%20b?q=1&r=2

Encoding a whole URL as a component is right when you are putting it inside another URL, such as a redirect parameter, and wrong everywhere else.

Pitfalls

  • Encoding a full URL with the component scope by mistake gives you a link that no longer works, because the slashes and the question mark are gone.
  • A space is %20 in a URL and + in form data. Mixing them up is the usual cause of a stray plus sign in a search term.
  • Encoding twice turns %20 into %2520. Once decoded you get %20 back as literal text, which is where double encoded URLs come from.
  • encodeURIComponent leaves !, ', (, ) and * alone. That is legal but not what every parser expects.
  • A % not followed by two hex digits is not valid percent encoding, and decoding it fails rather than passing it through.
  • Non-ASCII is encoded as UTF-8 bytes, so one accented character becomes two escapes. Older systems that assumed Latin-1 produce different, incompatible output.
  • The fragment after # is never sent to the server. Encoding it does not make it private.
  • Decoding untrusted input can reveal characters your code assumed were escaped. Validate after decoding, not before.

Compatibility

The output follows RFC 3986 for URLs and the WHATWG URL Standard for form data. Encoding uses UTF-8, which every browser has used since IE 6 was current. The tool runs entirely in your browser and handles inputs up to about a megabyte.

Frequently asked questions

When do I use component and when do I use full URL?
Component when you are encoding a value that goes inside a URL. Full URL when the input is the URL itself.
Why is my space a plus sign?
That is form data encoding. In a query string both are seen by most servers, but only %20 is correct outside a form body.
What is double encoding?
Encoding an already encoded value. %20 becomes %2520, and the consumer sees the literal text %20 instead of a space.
Does this handle emoji?
Yes. They are encoded as their UTF-8 bytes, which is four escapes per emoji.
Is percent encoding a security measure?
No. It makes a value safe to transport in a URL. Validation and escaping for the destination context are separate jobs.
Weekly drops

New tools, when there are new tools

One email when something worth using ships. No schedule to fill, so no filler.

Your address goes nowhere else, and one click unsubscribes.