URL Encoder/Decoder

No. Encoding and decoding both run entirely in your browser using JavaScript's built-in encodeURI, encodeURIComponent, decodeURI, and decodeURIComponent functions — there's no server-side component processing your input at any point. This means you can safely encode or decode sensitive URLs, API tokens embedded in query strings, or internal application data without it ever being transmitted or logged anywhere outside your own browser tab. You can verify this by watching your browser's network tab while using the tool: there are no outgoing requests carrying your text. Even without an internet connection (after the page has loaded), encoding and decoding will continue to work exactly the same, since the entire process depends only on your browser's built-in JavaScript engine.

Full URL encoding (using encodeURI) is designed for encoding an entire, already-structured URL, and deliberately leaves reserved characters like :, /, ?, #, &, and = untouched, since those are doing their job as URL syntax. Component encoding (using encodeURIComponent) is designed for encoding a single piece of data — like one query parameter's value — and escapes nearly everything except letters, digits, and a few unreserved symbols, including those reserved characters. Use Full URL mode when you have a complete URL you want to lightly clean up without breaking its structure; use Component mode when you have one specific value that you're about to insert into a URL and need fully escaped so it can't be misinterpreted as URL syntax.

Decoding fails when the input contains a malformed percent-encoded sequence — most commonly a '%' character that isn't followed by exactly two valid hexadecimal digits, which is invalid according to the URL encoding specification and can't be unambiguously converted back to a byte value. This can happen if you paste text that contains a literal, unencoded '%' sign (common in things like discount codes or percentages) while in Decode mode, since the decoder has no way to distinguish an intentional literal percent sign from the start of a broken encoded sequence. The tool catches this and shows a clear error message rather than silently producing garbled output. If you hit this, double-check that you're actually decoding text that was properly encoded in the first place.

Spaces are encoded as %20 under both Full URL and Component modes in this tool, which is the standard, universally correct way to represent a space in a URL per RFC 3986. You may also see spaces represented as a '+' character in some contexts — that's a different, older convention specific to the application/x-www-form-urlencoded format used when HTML forms submit data, not part of the general URL-encoding standard that encodeURI and encodeURIComponent implement. The '+' convention can cause confusion because a literal '+' character in your data also needs to be encoded (to %2B) to avoid being misread as an encoded space in that specific form-submission context — one of several reasons URL encoding conventions can seem inconsistent across different systems.

Yes, but you'll typically get the best result by encoding just the parts that need it, rather than the whole URL at once. If your URL is already well-formed and you just want to escape a few unsafe characters (like a space or accented character) without touching its structure, Full URL mode is the right choice — it'll leave the ://, /, ?, and & characters alone. If you're building a URL from scratch and need to insert a value that might contain special characters into a query parameter, encode just that value using Component mode, then manually assemble it into the full URL string with the already-safe structural characters (?, &, =) added around it.

No, they're different encodings for different purposes, even though both convert data into an ASCII-safe representation. URL encoding (percent-encoding) is character-based: it looks at each character in your text and replaces only the ones that are unsafe or reserved in a URL, leaving safe characters completely unchanged. Base64 encoding is byte-based: it re-encodes the entire input, safe characters included, into a completely different representation using a 64-character alphabet, always increasing the length by roughly 33% regardless of the original content. URL encoding is used specifically for embedding data inside a URL; Base64 is used more broadly for representing arbitrary binary data as text in emails, JSON payloads, and data URIs. If you need both, apply Base64 first, then URL-encode the result, since Base64's own alphabet includes + and / characters that need URL escaping.

This tool uses JavaScript's encodeURIComponent and encodeURI functions, both of which represent a space as %20, following the general URL/URI encoding standard defined in RFC 3986. The alternative representation, a literal '+' character for spaces, comes from a different, narrower specification (the application/x-www-form-urlencoded content type used specifically for HTML form submissions), implemented by different tooling rather than encodeURIComponent. Both representations are 'correct' in their respective contexts, but they aren't interchangeable — a system expecting %20 won't necessarily decode a literal + back into a space, and vice versa, which is why it's worth checking which convention the specific system you're working with actually expects.

Yes. Non-ASCII characters — accented letters, Chinese or Arabic text, emoji, and any other Unicode character — are fully supported for both encoding and decoding, since JavaScript's encoding functions operate on the UTF-8 byte representation of your text under the hood. A single accented character like 'é' typically encodes to two percent-encoded bytes (%C3%A9), while an emoji can encode to four bytes or more, since emoji are represented by multiple UTF-8 bytes internally. This is exactly why URL encoding exists in the first place — URLs are technically restricted to a small set of ASCII characters, so any non-ASCII text needs to be converted into that safe percent-encoded byte representation before it can be safely included in a URL.

Generally, just the specific parts that contain user-provided or unpredictable data — never the entire URL as a single Component-encoded blob, since that would break its structural characters (://, /, ?, &, =). The typical, correct pattern when building a URL programmatically is to encode each dynamic value individually with Component encoding, then assemble the final URL by combining those encoded values with the literal structural characters. For example, to build a search URL, encode just the search term with Component mode, then insert it after '?q=' yourself, rather than running the whole 'https://example.com/search?q=your term' string through the encoder as one piece — that would incorrectly escape the '://' and '?' characters that need to stay literal.

The special characters reference table shows exactly how a set of commonly-encountered characters — spaces, punctuation, and reserved URL syntax characters — are represented under Full URL encoding versus Component encoding, side by side. It's there so you can quickly look up how a specific character will be transformed without needing to type it into the tool and check the result yourself, and to make the difference between the two encoding modes concrete rather than abstract: you can see directly that a character like '&' stays literal under Full URL mode but becomes %26 under Component mode, which is often the exact detail that explains why a URL is behaving unexpectedly.