FileKiln

URL Encoder / Decoder

Percent-encode text for URLs or decode %-sequences back to text, in your browser. Component mode encodes everything; full-URL mode preserves separators.

Ready when you areurl ⇄ text
Runs on your computer. Nothing gets uploaded.

Your stuff stays yours. The conversion happens in this page's JavaScript. Nothing you paste here leaves your machine, and the tool keeps working with the network unplugged.

Two modes, because there are two jobs. Component mode encodes every reserved character, which is what you want for a single query-string value. Unchecking it switches to whole-URL mode, which leaves structural characters like /, ? and & intact so a full URL stays a URL. Decoding also converts + to spaces, matching how HTML forms encode them.

How to use the URL encoder and decoder

  1. Paste your text or URL into the Input box.
  2. Decide on the mode before encoding. Leave the component mode checkbox ticked (the default) when the input is a single value, such as a search term or a redirect address that will sit inside a query parameter. Untick it when the input is an entire URL that should keep working as a URL.
  3. Click Encode to percent-encode the input, or Decode to turn percent sequences back into characters. The checkbox only affects encoding; decoding always works the same way.
  4. Read the result in the Output box, then use Copy result or Clear.

How percent-encoding works

A URL can only contain a limited set of ASCII characters, and some of those have jobs. / separates path segments, ? starts the query, & separates parameters, = separates a name from its value, and # starts the fragment. Any character that is not allowed, or that would be mistaken for one of those separators, is replaced by a % followed by two hex digits.

For characters outside ASCII, the text is first converted to UTF-8 bytes, and each byte gets its own percent sequence. That is why é, which is two bytes in UTF-8, becomes %C3%A9. A space becomes %20 and a literal percent sign becomes %25. This tool never writes a space as + when encoding.

The two modes differ only in which ASCII punctuation they leave alone:

ModeLeft unencoded
Component (checked)Letters, digits, and - _ . ! ~ * ' ( )
Whole URL (unchecked)All of the above, plus ; , / ? : @ & = + $ #

A worked example

With component mode checked, encode this value:

Tom & Jerry: 50% off?

The output is:

Tom%20%26%20Jerry%3A%2050%25%20off%3F

Every space, the ampersand, the colon, the percent sign, and the question mark were encoded, so the value can be placed after ?q= without changing the structure of the URL around it.

Now untick component mode and encode a whole URL that contains the same kind of value:

https://example.com/café menu?q=Tom & Jerry

The output is:

https://example.com/caf%C3%A9%20menu?q=Tom%20&%20Jerry

The accented letter and the spaces are encoded and the URL's structure is intact, but the & inside the search term was left alone too. A server will read this as a parameter q with the value Tom followed by a second parameter named Jerry with no value. Whole-URL mode cannot tell which ampersands are separators and which are data. The reliable method is to encode each value on its own in component mode, then assemble the URL.

Decoding reverses the process. C%2B%2B+tips decodes to C++ tips: each %2B becomes a real plus sign, and the bare + becomes a space.

Common problems and how to fix them

"URI malformed" when decoding

The decoder found a % that is not followed by a valid sequence. Firefox calls this a "malformed URI sequence". Three things usually cause it:

  • A literal percent sign, as in 100%. In a properly encoded string it would be 100%25. Replace lone percent signs before decoding.
  • Legacy encoding. Some older systems encoded é as the single byte %E9 (Latin-1) instead of the UTF-8 pair %C3%A9. That byte on its own is not valid UTF-8, so decoding fails.
  • Bad hex, such as %zz or a sequence cut off at the end of a copied string.

Plus signs turned into spaces

The decoder follows the HTML form convention and reads every bare + as a space. That is correct for query strings from forms, but wrong for paths or other data where + was meant literally, such as a phone number like +15551234567. If your plus signs are real, replace each one with %2B before clicking Decode.

Output full of %2520

The input was already encoded and got encoded again: the % of %20 became %25. Both modes do this. Decode the string first, then encode it once.

A decoded URL no longer works

Decoding converts everything, including %26, %3D, and %2F that were protecting data inside the URL. The result is good for reading but may point somewhere else if you paste it into a browser. Keep the encoded version for links.

Related tasks

For embedding text in HTML rather than in a URL, use the HTML entity encoder. Tracking parameters are easier to assemble correctly with the UTM builder. If a query parameter holds Base64, decode that value with the Base64 decoder, but check it first: a bare + in Base64 is data, and this tool would turn it into a space.

Questions this tool gets asked

When do I need component mode?

When encoding one value that goes inside a URL, like a search term for a query parameter. Whole-URL mode is for encoding an already-structured URL without breaking it.

Why does + decode to a space?

HTML form submissions historically encode spaces as +. This decoder treats + as a space, which matches what servers receiving form data expect.

What standard does this follow?

The encodeURIComponent and encodeURI functions implement RFC 3986 percent-encoding, the standard all modern browsers and servers use.

Related tools