Toolypet
DEVELOPER TOOL

URL Encoder / Decoder

Encode and decode URL components with percent-encoding. Essential for building query strings, debugging API calls, and handling special characters in URLs.

Result
Result will appear here...

Percent-Encoding Demystified

Why URLs Need Encoding

RFC 3986 defines URLs as sequences of characters from a limited set: letters, digits, and a handful of special characters (-._~). Everything else — spaces, ampersands, non-ASCII characters, equals signs — must be percent-encoded. A space becomes %20, an ampersand becomes %26, and the Korean character “한” becomes %ED%95%9C (3 UTF-8 bytes, 9 characters encoded). Without encoding, a URL like ?q=rock&rollis ambiguous: is “roll” a separate parameter or part of the value?

encodeURI vs. encodeURIComponent

encodeURI: preserves :, /, ?, #, &, =

encodeURIComponent: encodes :, /, ?, #, &, =

JavaScript provides two functions with a critical difference. encodeURI encodes a complete URL but preserves structural characters like :// and / so the URL remains navigable. encodeURIComponent encodes everything except letters, digits, and - _ . ~ ! * ' ( ), making it the correct choice for query parameter values. This tool uses encodeURIComponent — the safer option for most developer use cases.

Unicode and Internationalized URLs

Modern URLs frequently contain non-ASCII characters: CJK characters, Arabic script, emoji, and accented letters. Percent-encoding converts these via UTF-8 first: a 2-byte character like “é” becomes %C3%A9, while a 4-byte emoji like “😀” becomes %F0%9F%98%80. Internationalized Domain Names (IDNs) use Punycode separately, but path and query components rely entirely on percent-encoding. Getting this wrong leads to broken links, failed API calls, and search engines misindexing your content.

Common Double-Encoding Pitfalls

One of the most common bugs in web development is double encoding: encoding an already-encoded string. A space becomes %20, but if encoded again, the % becomes %25, producing %2520. This often happens when frameworks automatically encode URL parameters and developers manually encode them first. The reverse problem — double decoding— can also corrupt data. Always check whether your HTTP client or framework already handles encoding before applying it manually.

Frequently Asked Questions

When should I use encodeURI instead of encodeURIComponent?

Use encodeURI when you have a complete URL and want to encode only the characters that are invalid in URLs while preserving the structure (://, /, ?, #, &). Use encodeURIComponent when encoding individual parameter values, path segments, or any string that will become part of a larger URL. In practice, encodeURIComponent is the correct choice 90% of the time.

Why does + sometimes represent a space in URLs?

The application/x-www-form-urlencoded format (used by HTML forms) encodes spaces as + instead of %20. This is a legacy convention from HTML 2.0. Modern APIs prefer %20 per RFC 3986. When decoding, be aware of which format was used: %20 is always safe, but + is only a space in form data contexts.

Can I encode an entire URL to pass it as a query parameter?

Yes, and this is the correct approach. For example, a redirect URL like?redirect=https://example.com/path?a=1&b=2 must have the value encoded: ?redirect=https%3A%2F%2Fexample.com%2Fpath%3Fa%3D1%26b%3D2. Without encoding, the & in the inner URL creates an ambiguous outer parameter boundary.