URL Encode / Decode

About this URL encoder and decoder

URLs can only carry a limited set of characters, so spaces, accents, ampersands and most symbols have to be percent-encoded: a space becomes %20 and ñ becomes %C3%B1. Paste your text, press Encode or Decode, and the result appears below. The conversion runs entirely in your browser, so a query string containing tokens or customer data never leaves your device.

There are two modes. Component mode uses encodeURIComponent and escapes everything that is not a letter, a digit, or one of - _ . ! ~ * ' ( ) — including /, ?, & and =. Use it for a single value going into a query string. Full-URL mode uses encodeURI, which leaves the structural characters intact so the address still works as an address. Component mode is what you want most of the time; full-URL mode is for cleaning up a whole URL someone pasted with spaces or accents inside it.

Percent-encoding operates on bytes, not characters. Each byte becomes a % followed by two hexadecimal digits, so anything outside ASCII expands: é is one character but two UTF-8 bytes (C3 A9), which is why it encodes to %C3%A9 rather than a single triplet. RFC 3986 treats %c3%a9 and %C3%A9 as the same value and recommends uppercase hex when normalizing. It also defines a set of unreserved characters — A–Z, a–z, 0–9, hyphen, period, underscore and tilde — that never need encoding; encoding them anyway yields a URI that is technically equivalent but longer and harder to read.

Two mistakes account for most of the trouble. The first is double encoding: run the same string through an encoder twice and every % becomes %25, so caf%C3%A9 turns into caf%25C3%25A9. If you see %25 in a URL, something encoded an already-encoded string, and one decode pass will only get you halfway back. The second is the plus sign. In form-encoded query strings a + means a space, but decodeURIComponent does not know that and returns a literal +. This tool takes the pragmatic route and converts every + to a space before decoding — correct for form data, wrong if your value legitimately contains a plus, such as a base64 payload or a phone number in +1 format. In that case the + should have been encoded as %2B before it ever reached the URL.

Do not use this as a substitute for building URLs properly. If you are assembling an address in code, the URL and URLSearchParams objects handle escaping, parameter joining and the + convention for you, and are far harder to get wrong than string concatenation. Percent-encoding is also not HTML escaping — for < and & inside markup you want HTML entities. And it does not apply to the domain: an internationalized hostname like piñata.mx becomes Punycode (xn--piata-pta.mx), not percent-encoded. One last limit: encodeURIComponent throws a URIError on a lone surrogate, the unpaired half of an emoji, so text copied from a broken source can refuse to encode at all.