URL Encoder / Decoder

Percent-encode text for URLs or decode percent-encoded strings — with component and full-URL modes and precise error locations. Free, no sign-up — runs locally in your browser.

Your work is auto-saved in this browser only, so a refresh won't lose it. Nothing is uploaded.

What is percent-encoding?

A URL can only contain a small, safe alphabet: letters, digits and a handful of symbols. But URLs constantly need to carry things outside that alphabet — a search query with spaces and an ampersand, a filename in Chinese, a redirect target that is itself a URL. Percent-encoding is the escape hatch: any byte that cannot appear literally is written as a percent sign followed by two hexadecimal digits giving its value, so a space becomes %20 and the byte 0xE4 becomes %E4. It is the same idea as backslash escapes in a string literal, standardised for the one string format the whole web shares. Every browser, server framework and HTTP library implements it, which is exactly why its details matter: two implementations that disagree about one character produce links that break in only one direction.

How to use this tool

  1. Paste your text or encoded string into the box above.
  2. Choose the mode. Component is right for a single value that will live inside a URL (a query parameter, a path segment): it encodes / ? & = too. Full URL is for an existing URL that needs to become legal: it keeps the structure and encodes only what cannot appear.
  3. Press Encode or Decode. Decoding reports the exact position of a malformed % sequence instead of failing silently.
  4. When decoding form submissions, tick Read + as space — the rest of the time, leave it off, because in a standards-based URL a plus sign is a plus sign.

Reserved, unreserved, and who gets encoded

RFC 3986 splits characters into three castes. Unreserved characters (A–Z a–z 0–9 - . _ ~) are always safe and never need encoding. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) are the URL's punctuation: they mean something where they stand, so to use one as mere data — an ampersand inside a company name, a slash inside a filename — it must be percent-encoded. Everything else, including all non-ASCII text, is encoded byte by byte as UTF-8. Component mode encodes the reserved set; full-URL mode trusts that your reserved characters are punctuation and leaves them working. Picking the wrong mode is the single most common URL bug in production code: an unencoded & in a value quietly splits one parameter into two, and the debugging session starts two subsystems away from the cause.

Examples

The query value Lovelace & Byrd: 100€? encodes in Component mode to:

Lovelace%20%26%20Byrd%3A%20100%E2%82%AC%3F

Note the ampersand became %26 (it can no longer split parameters), the euro sign became three percent-encoded UTF-8 bytes, and the question mark became %3F so it cannot start a second query string. The full URL https://example.com/search?q=café menu in Full URL mode keeps every structural character and encodes just the é and the space:

https://example.com/search?q=caf%C3%A9%20menu

If a string you decode comes back with %20 still visible in it, it was encoded twice — decode it once more and you will see the singly-encoded original.

Frequently asked questions

What is the difference between encodeURI and encodeURIComponent?

They answer different questions. encodeURIComponent encodes a single component — one query value, one path segment — so it escapes everything structural: /, ?, &, = all become percent sequences. encodeURI encodes a whole URL, so it deliberately leaves the structural characters alone and only escapes what could not legally appear at all (spaces, non-ASCII, and a few symbols). Use Component mode for a value you are putting into a URL, Full URL mode for an existing URL you need to make legal.

Why is a space sometimes %20 and sometimes +?

Both exist because two standards grew up in parallel. In the path and in a standards-based query string a space is %20. In HTML form submissions (application/x-www-form-urlencoded) a space is written +. The decoder above treats + as a literal plus sign unless you tick "Read + as space", which you should do only for strings you know came from a form submission or an old query string.

How does percent-encoding handle Chinese or emoji?

The character is first encoded as UTF-8 bytes, then each byte is percent-encoded. 中 becomes the three bytes E4 B8 AD, written %E4%B8%AD. Decoding is the reverse: collect the bytes, then interpret them as UTF-8. This is why a sequence can be perfectly well-formed percent-encoding and still fail to decode — the bytes may not be valid UTF-8, which usually means the original text used a legacy encoding such as GBK or Latin-1.

Why did my link break after encoding?

The classic causes: encoding an already-encoded string (double encoding turns %20 into %2520, which decodes to the literal text %20, not a space); using Full URL mode on a query value, leaving & and = bare so one parameter becomes several; and encoding the whole URL after building it from unencoded parts that contained ? or #. Encode each component first, then assemble — or decode once and check what you actually have.

Which characters never need encoding?

The unreserved set from RFC 3986: A–Z, a–z, 0–9 and - . _ ~ — these are safe everywhere in a URL and decoders must produce them verbatim. Everything else either has a structural job (the reserved characters : / ? # [ ] @ ! $ & ' ( ) * + , ; =) or must be percent-encoded to appear as data.

Is my text uploaded to a server?

No. Encoding and decoding run in your browser. Query strings often carry tokens and personal data, so keeping them local is not a nicety — it is the point. You can disconnect from the network and the tool keeps working.

Related tools

Related guides