How to URL Encode and Decode Text (And What encodeURIComponent Actually Escapes)

Paste text into the URL encoder, choose Encode or Decode, and the result appears live - no Run button, nothing uploaded. The tool uses component-level percent-encoding throughout (the same convention explained in detail here if you're weighing which of the three real URL-encoding conventions you actually need), so knowing exactly what it escapes and what it leaves alone is worth a minute before you rely on it.

What Encode actually escapes

Encode runs the platform's own encodeURIComponent, which leaves unreserved characters - letters, digits, and - _ . ! ~ * ' ( ) - untouched, and percent-encodes everything else. A space becomes %20, not + - this tool deliberately does not use the older form-submission convention, explained in the why guide linked below. Reserved characters that have structural meaning in a URL - & = ? / # among others - are always escaped too, because encodeURIComponent has no way to know whether your text is a whole URL or a single value going inside one, and it assumes the safer case: a single value, where those characters need escaping to avoid being misread as URL structure.

A quick reference for the characters that come up most: space becomes %20, & becomes %26, = becomes %3D, ? becomes %3F, # becomes %23, / becomes %2F, + becomes %2B (worth noting specifically, since a literal plus sign and an encoded space look identical once decoded by something using the form convention instead), and a literal % becomes %25 - the exact case the double-encoding warning below is about.

What Decode reverses, and when it can't

Decode runs decodeURIComponent on a percent-encoded string and returns the original text. If the input contains a malformed sequence - a lone % not followed by two hex digits, or a valid-looking hex pair that doesn't decode to valid UTF-8 - the platform function throws rather than guessing, and this tool shows a clear message instead of letting that error reach the console unhandled or silently returning a broken partial result.

A worked example, checkable by hand

Encoding café & co produces caf%C3%A9%20%26%20co - the plain letters stay as-is, the space becomes %20, the & becomes %26, and é becomes %C3%A9, its two-byte UTF-8 representation, both bytes escaped separately. Decoding that same string returns café & co exactly - a full round trip with no character lost or altered, including the accented letter and the reserved punctuation.

Arabic text encodes the same way, just with more bytes per character: مرحبا becomes %D9%85%D8%B1%D8%AD%D8%A8%D8%A7, and decoding that string returns the exact original word. Nothing about the process changes for a right-to-left script - encodeURIComponent works on Unicode code points regardless of which direction the text reads, so there's no separate mode or setting needed to get Arabic query values right.

The one mistake worth knowing about before it happens

Running Encode on text that is already percent-encoded double-encodes it: the literal % character itself gets escaped to %25, turning a working %20 into a broken %2520. There is no reliable way for the tool to detect this automatically - a string containing a literal percent sign and an already-encoded string can look identical - so it doesn't try to guess, and checking whether your input is already encoded before you encode it again is worth the extra second it takes.

Why an escaped slash in a full path isn't a bug

Encoding a full path like /reports/2026 escapes the slash itself, producing %2Freports%2F2026 - correct, documented behavior for a component-level encoder, since it has no way to know a slash in your input was meant to stay structural rather than be a literal character inside one value. If you're encoding a whole path rather than a single value, that's a different job than this tool is built for.

Text up to 200,000 characters converts live, entirely in your browser, with no upload at any point.