URL Encode/Decode

URL encoding, briefly

URLs were originally specified to carry a small alphabet of safe characters: letters, digits, and a handful of punctuation marks like -, _, ., and ~. Anything outside that set — spaces, ampersands, slashes appearing inside a query value, accented letters, emoji — has to be percent-encoded: each unsafe byte becomes % followed by its two-digit hex value. Without this rule, a URL containing a literal ? or & in a search term would be parsed as the start of a query string and break.

This page handles three related operations: encoding text so it's safe to drop into a URL, decoding text that's already been encoded, and parsing a complete URL into its components. All of it runs in your browser using the standard encodeURIComponent, decodeURIComponent, and URL APIs.

encodeURI vs. encodeURIComponent

This is the gotcha that bites people. Both encode a string for use in a URL, but they treat reserved characters differently:

• encodeURI assumes you're passing a complete URL and leaves :, /, ?, #, &, and = alone, because those have structural meaning.
• encodeURIComponent assumes you're passing one piece — a single query value, a path segment, a fragment — and encodes everything that isn't strictly safe.

The right choice depends on context. If you're building a URL piece by piece and inserting user input as a query value, you want encodeURIComponent. If you have a full URL with possibly-unsafe characters in unexpected places and you just want to repair it, encodeURI is gentler. This tool uses encodeURIComponent for the encode action because that's the right answer in 90% of real cases.

What "Parse URL" shows you

Paste a complete URL and the parser breaks it into its named parts: protocol, hostname, port, path, query string, and hash fragment. Query parameters are split out individually, with each value already decoded. This is the fastest way to see what's actually in a long URL — the stack of tracking parameters at the end of marketing links, the auth token in a password-reset email, the precise shape of a redirect chain.

Common cases

• Building a search URL. Encoding hello world gives hello%20world. Some legacy systems use + for spaces in query strings; both are technically valid in application/x-www-form-urlencoded.
• Non-ASCII characters. The Japanese character 日 encodes to %E6%97%A5 — three bytes in UTF-8, six characters in the URL.
• Already-encoded input. Encoding an already-encoded string double-encodes it: %20 becomes %2520. If you see %25 sequences appearing where you don't expect them, you have a double-encoding bug somewhere upstream.
• Decoding malformed input. A bare % not followed by two hex digits will throw. The most common cause is someone forgetting to encode % itself before passing the string back through the system.

What's safe to leave alone

The unreserved set — letters, digits, -, _, ., ~ — never needs encoding under any current spec. Older RFCs sometimes encoded ~; modern ones don't. If you're seeing %7E in URLs, it's harmless but unnecessary.