URL Encoder, Decoder, and Base64 Text Converter

URL encoding — often called percent encoding — represents a byte with a percent sign followed by two hexadecimal digits. A space encoded by this tool becomes %20, while characters outside the unescaped set are represented by their UTF-8 bytes:

Input:  coffee & tea
Output: coffee%20%26%20tea

The ampersand must be encoded when it is data inside a query value; otherwise it can be interpreted as the separator before another parameter. This tool uses JavaScript's encodeURIComponent(), which is intended for a component, not an entire already-structured URL.

Select URL Encode, enter only the value that needs encoding, choose Convert Now, then place the result into the correct URL structure. A search value such as red shoes & socks becomes red%20shoes%20%26%20socks and can be inserted as a parameter:

https://example.com/search?q=red%20shoes%20%26%20socks

encodeURIComponent() also encodes structural delimiters such as :, /, ?, =, and &. Encoding the complete URL https://example.com/search?q=blue produces something like:

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dblue

That is useful only when the whole URL must become a value inside another context; it is not directly navigable as the same URL. Encode individual dynamic components while preserving the URL's intended structure, and prefer a URL API or framework utility over manually concatenating untrusted strings.

encodeURIComponent() leaves ASCII letters, digits, and this set unescaped:

- _ . ! ~ * ' ( )

Other characters are converted to percent escapes based on UTF-8. Standards or signing protocols can require stricter canonical encoding than JavaScript's default, so for OAuth signatures, cloud API signing, or another specification, follow its exact normalization rules rather than assuming any general URL encoder is sufficient. Hexadecimal digits in percent escapes may appear uppercase or lowercase and still represent the same byte in ordinary URL processing, although signature systems can require a canonical representation.

Select URL Decode and paste a percent-encoded component. The decoder uses decodeURIComponent() and expects complete, valid percent-encoded UTF-8 sequences:

Input:  M%C3%BCnchen%20caf%C3%A9
Output: München café

A stray %, an incomplete escape such as %2, or bytes that do not form valid UTF-8 produce an error in the output. Note that HTML form encoding commonly represents spaces as + in application/x-www-form-urlencoded data, but decodeURIComponent() does not apply that rule — red+shoes decodes to red+shoes. If you are decoding a form query component, convert + to a space according to the form specification first, or use a proper query-string parser; do not blindly replace plus signs when + is legitimate data. Likewise, URL Encode produces %20 for a space rather than +.

Encoding an already-encoded value changes percent signs into %25:

Original:       red shoes
Encoded once:   red%20shoes
Encoded twice:  red%2520shoes

One decode of the double-encoded string produces red%20shoes, not red shoes. Double encoding is a common source of broken redirects, failed API signatures, and security-filter inconsistencies. Define which layer owns encoding and encode exactly once for that context.

Base64 converts bytes into characters from an ASCII alphabet — uppercase and lowercase letters, digits, +, and /, with = used as padding when required — and it is reversible representation, not secrecy. Select Base64 Encode (Text) to represent text; the implementation first converts the JavaScript string to UTF-8 bytes and then calls the browser's Base64 encoder, so ordinary Unicode such as accented characters and emoji work when they form valid strings:

Input:  Hello
Output: SGVsbG8=

Select Base64 Decode (Text) to reverse standard Base64. The browser decodes it into bytes and then interprets those bytes as UTF-8, so if the bytes represent an image, archive, or text in another encoding, UTF-8 conversion can fail or produce incorrect characters — use a binary/file Base64 tool for non-text data. The output uses standard Base64, including +, /, and any required = padding.

Base64 normally increases size: every three input bytes become four Base64 characters, plus possible padding — roughly a 33% increase before surrounding formatting. Repetition can compress well later under gzip or Brotli, but Base64 itself is encoding, not compression. Embedding small resources can reduce network requests in some contexts, yet large Base64 blobs increase document size, memory use, and parsing overhead.

Do not place a password, API token, or private key into Base64 and assume it is protected. Base64 strings are recognizable and trivial to decode.

The Base64 implementation uses a traditional encodeURIComponent/unescape bridge for UTF-8 encoding and the reverse bridge when decoding. It handles normal Unicode text but can throw for malformed JavaScript strings containing an isolated surrogate code unit. A decoded byte stream must also be valid UTF-8: standard Base64 can represent any bytes, but this specific mode only returns text, so if you need robust byte-level conversion, use TextEncoder, TextDecoder, typed arrays, and file APIs in application code.

URL decoding also requires valid UTF-8 percent sequences. Legacy sites sometimes percent-encode bytes in a local character set rather than UTF-8, and a modern component decoder may reject or misinterpret them.

The four operations run through native JavaScript functions in the browser and do not require an encoding API call. Even so, avoid pasting live credentials or confidential personal data, because clipboard history, browser extensions, screen capture, and a compromised device can expose text regardless of where conversion runs.

The tool handles pasted text only. It does not upload files, create downloads, generate data URLs, or convert images despite broader Base64 use cases.