Escape Encode / Decode

The escape() function: what it does and why you should no longer use it

What escape() does

escape() is an early JavaScript function that rewrites characters as %XX or %uXXXX. The crucial detail is that it works on UTF-16 code units, not UTF-8 bytes. So a Chinese character is written as a single %u4E2D sequence rather than three %E4%B8%AD groups. That single difference is the whole source of incompatibility with everything else.

The practical upshot is that a string produced by escape() and a string produced by encodeURIComponent for the same input look completely different, even though both claim to "encode" it. If you have ever seen a URL full of %u sequences sitting next to a normal %E4 URL, you are looking at the two encodings side by side, and only one of them will survive a round trip through a standards-compliant server.

Why it should be retired

• No standard endorses it. The %uXXXX form appears in neither the URL specification nor the ECMAScript specification — it is just leftover behavior from early browsers. Standard libraries in other languages do not recognize that format at all.
• It skips characters that should be escaped. Characters like @, *, +, and / pass through escape() untouched, yet all of them carry special meaning inside a URL.
• A standard replacement exists. encodeURIComponent encodes by UTF-8 bytes, interoperates across languages, and is the only correct choice.

The ECMAScript specification has marked escape as deprecated (Annex B, retained only for backward compatibility with old web pages), and implementations are free to remove it.

Taken together, these three points mean escape() is both incomplete and non-portable. It leaves dangerous characters unescaped, it emits a format nobody else parses, and it disagrees with the UTF-8 world on what a non-ASCII character even is. There is no scenario where it is the best tool for new code.

When you still need it

The main reason is handling historical data: URLs exported by legacy systems, old logs, and old CMS platforms may still carry %uXXXX encodings, and some front-end frameworks from the mid-2000s wrote escape() output straight into the database. When you must parse that data you need a way to reverse it, which is exactly why this tool keeps the function around.

For any new data you need to encode, use the URL tool and follow the encodeURIComponent rule. This tool displays both results side by side so you can confirm which family the string in front of you actually belongs to.