URL Encoder & Decoder

Encode text for safe use in URLs or decode percent-encoded URLs back to readable text — instantly.

How to use

  1. Choose the Encode or Decode tab.
  2. Type or paste your text or URL.
  3. On Encode, pick component or full-URL encoding.
  4. The result appears instantly — copy it with one click.

What is URL encoding?

URL encoding, also known as percent-encoding, is the process of converting characters into a format that can be safely transmitted in a URL. URLs may only contain a limited set of characters from the ASCII alphabet, so any character outside that set — spaces, accented letters, symbols like &, ? and =, or emoji — must be replaced with a percent sign followed by its hexadecimal byte value. A space, for example, becomes %20, and an ampersand becomes %26. Decoding reverses the process, turning those percent-escapes back into the original readable characters.

This tool encodes text for safe use in URLs and decodes percent-encoded URLs back to plain text, instantly and entirely in your browser. Nothing is uploaded, so even sensitive query strings stay private on your device.

How percent-encoding works

Under the hood, URL encoding first converts a character to its bytes using UTF-8, then writes each byte as % followed by two hexadecimal digits. Because a space is byte value 32 (hex 20) it becomes %20; the ampersand (38, hex 26) becomes %26. Multi-byte characters such as é or 🚀 become several percent-escapes in a row, one per UTF-8 byte. The decoder reads each %XX sequence, reassembles the bytes, and interprets them back as UTF-8 text. This is why a correct URL decoder restores international characters and emoji perfectly, while a naive one can produce garbled output.

Reserved vs unreserved characters

Not every character needs encoding. The URL standard (RFC 3986) defines unreserved characters — the letters A–Z and a–z, the digits 0–9, and the four symbols -, _, . and ~ — which are always safe and are never encoded. Reserved characters such as /, ?, #, &, =, : and @ have special meaning in a URL (separating the path, query, fragment and parameters), so whether they should be encoded depends on context. When a reserved character is part of your data rather than the URL's structure — for example an ampersand inside a search term — it must be encoded so it is not mistaken for a separator. Everything else outside the unreserved set is encoded to be safe.

Component encoding vs full-URL encoding

There are two common levels of URL encoding, and this tool supports both. Component encoding (the most common) encodes a single piece of data — such as one query-string value — and escapes all reserved characters, including /, ?, & and =. This is what you want when inserting a value into a query parameter, because it guarantees the value cannot break the URL's structure. Full-URL encoding is gentler: it leaves the characters that form a valid URL (like / and ?) untouched and only encodes the rest, which is appropriate when you are encoding an entire URL that is already correctly structured. Choosing the wrong one is a common bug — encoding a whole URL with component encoding turns its slashes into %2F and breaks it, while component-encoding a value with full-URL encoding can leave dangerous separators in place. The encode mode here lets you pick whichever fits your situation.

Common use cases

  • Query string parameters. Safely add search terms, names or any value containing spaces or symbols to a URL.
  • API requests. Build correct request URLs and form-encoded bodies where every value must be escaped.
  • Sharing links. Encode links that contain special characters so they survive being pasted into chats, emails and documents.
  • Debugging. Decode a long, percent-encoded URL to read exactly what parameters and values it carries.
  • Redirects and tracking. Encode a destination URL so it can be passed as a parameter inside another URL.

Common pitfalls

A few issues trip people up. The first is spaces: in the path and query of a URL a space is encoded as %20, but in older application/x-www-form-urlencoded form data it is encoded as +. The two are not interchangeable in every context, so know which your target expects. The second is double encoding — accidentally encoding text that is already encoded, turning %20 into %2520. If a decoded URL still shows percent-escapes, it was probably encoded twice; decode again. The third is malformed input: a stray % that is not followed by two valid hex digits is not legal percent-encoding, and a strict decoder will report an error rather than guessing. This decoder tells you clearly when input cannot be decoded, so you can fix it.

How to use this tool

Switch to the Encode tab to convert text into a URL-safe form, choosing component or full-URL encoding, or the Decode tab to turn an encoded URL back into readable text. Conversion is live as you type, and you can copy the result with one click. Everything runs locally in your browser, so it is fast, works on any device, and keeps your data private — no sign-up, no uploads, no limits.

Frequently asked questions

URL encoding (percent-encoding) converts characters that are not allowed in a URL into %XX escapes, so a space becomes %20, for example.

Yes, completely free with no sign-up.

No. Encoding and decoding happen in your browser, so your URLs and text never leave your device.

Component encoding escapes all reserved characters (for a single value); full-URL encoding leaves URL-structure characters like / and ? intact.

In a URL path or query a space is %20, but in form-encoded (application/x-www-form-urlencoded) data it is often +. Use the one your target expects.

The unreserved characters: letters, digits, and the symbols hyphen, underscore, period and tilde are always safe.

Yes. Text is encoded as UTF-8 bytes, so emoji and international characters encode and decode correctly.

The input is not valid percent-encoding — usually a stray % that is not followed by two valid hexadecimal digits.

Encoding already-encoded text, which turns %20 into %2520. If decoded output still shows escapes, decode it again.

Yes. The tool is fully mobile-responsive and works in any modern browser.