URL, HTML, Base64 Encoder & Decoder — Free Online Tool

The Five Schemes and How Each One Works

All five schemes solve the same problem in different alphabets: a character that means something structural in the destination has to be carried through it as data. The differences are which characters count as dangerous, and what the replacement looks like.

URL percent-encoding (RFC 3986)

A reserved or unsafe character is replaced by a percent sign and the two hexadecimal digits of each of its UTF-8 bytes: a space becomes %20, an ampersand %26, and the euro sign, being three bytes in UTF-8, becomes %E2%82%AC. Which characters get replaced depends on the mode. The encodeURIComponent button uses the browser's built-in function of that name, which leaves only letters, digits and - _ . ! ~ * ' ( ) alone — that is what you want for a single query value, because it encodes the &, =, ? and / that would otherwise be read as structure. The encodeURI button preserves those separators, so it is for encoding a whole address you have already assembled. Full URI is a looser third mode that only replaces characters outside the RFC 3986 reserved and unreserved sets; note that it deliberately leaves spaces untouched, so it is a repair pass for a nearly-valid URL rather than a general encoder.

HTML entity encoding

Entity encoding stops a browser from reading your text as markup, which is the core defence against reflected and stored cross-site scripting. In Named mode this tool escapes the seven characters that actually matter in an HTML or attribute context — &, <, >, ", ', backtick and / — and leaves everything else, including accented letters and symbols, as literal UTF-8. That is the modern recommendation: a page served as UTF-8 does not need é for é. Numeric mode is the aggressive option, converting every character above code point 127 into a &#NNN; reference, which is what you want when the output has to survive an ASCII-only pipeline. Decoding accepts both forms plus hexadecimal &#xHH; references and a long table of named entities.

Base64 (RFC 4648)

Base64 re-expresses arbitrary bytes in a 64-character alphabet that survives text-only channels. Three input bytes — 24 bits — are split into four 6-bit groups, and each group indexes the alphabet A–Z a–z 0–9 + /. When the input length is not a multiple of three, the output is padded with one or two = characters, which is why encoded lengths are always a multiple of four:

Text is converted to UTF-8 bytes before encoding, so accented letters, CJK text and emoji survive a round trip. Decoding strips whitespace and line breaks first, so Base64 copied out of a MIME email or a PEM-style block with 64- or 76-column wrapping pastes in directly. Base64 is an encoding, not a cipher — a Base64 credential is one atob call away from plaintext.

JavaScript string literals

This tab wraps your text in the quote style you choose and escapes what would otherwise terminate or corrupt the literal: backslashes are doubled, newlines and tabs become \n and \t, the enclosing quote character is backslash-escaped, and control characters become \xHH or \uXXXX. Template-literal mode also escapes $ so an accidental ${...} is not interpolated. Backtick mode leaves single and double quotes alone, because neither ends a template literal.

Unicode escapes

The Unicode tab converts every character to a numeric escape sequence, which is how you embed non-ASCII text in a source file, a properties file or a JSON payload that must stay ASCII-only. The tool walks the string by UTF-16 code unit, so a character outside the Basic Multilingual Plane — most emoji, for instance — is emitted as its two surrogate halves rather than as one code point: the grinning-face emoji at U+1F600 becomes \uD83D\uDE00, and in the eight-digit mode \U0000D83D\U0000DE00. Decoding is more capable than encoding here and will correctly rebuild a real \U0001F600 escape written by another tool. The \xHH mode uses two digits for code points up to 255 and silently falls back to \uXXXX above that.

Encoding Reference

The same handful of characters cause almost every encoding bug. This is what each scheme turns them into.

Choosing the Right Encoding

The rule that prevents most bugs is to encode at the moment of insertion, for the context you are inserting into, and exactly once. Encoding early and carrying the encoded value through your code leads to double-encoding, where %20 becomes %2520 and & shows up on screen as literal text. Encoding for the wrong context is worse: HTML-escaping a value and then putting it in a URL protects nothing, because the browser never applies HTML rules to a query string.

• URL: every value you append to a query string, path segment or form body. Use component mode for the value, not for the whole address.
• HTML: every piece of user-supplied text rendered into a page — comments, names, search terms echoed back. Escape on output, not on input, so the stored data stays clean.
• Base64: binary carried through a text channel — inline images in CSS, attachments in JSON, HTTP Basic credentials, the segments of a JWT. Never as a substitute for encryption.
• JS string: a literal you are pasting into source, a config file or a test fixture. For values injected into a page at runtime, serialise with JSON.stringify in your own code instead.
• Unicode escape: ASCII-only source and config formats, and inspecting text that contains invisible characters — zero-width spaces and non-breaking spaces become plainly visible as \u200B and \u00A0.

Use Cases

Related Tools