Text Encoder/Decoder

No. Every conversion — Base64, URL, HTML, Unicode, and ROT13 — runs entirely inside your browser using standard JavaScript and Web APIs, with no server-side component involved at any point. You can encode or decode sensitive text (tokens, private notes, internal data) without any of it ever leaving your device.

Use Base64 when you need to represent arbitrary binary-safe data (or plain text) as printable ASCII characters for embedding in places that don't handle raw bytes well — a JSON field, a data URI, an email attachment, an authorization header. Use URL encoding specifically when text needs to be safely included inside a URL — a query parameter value, a path segment — since it escapes characters that have special meaning in URL syntax (like &, ?, /, and spaces) without touching the rest. The two solve different problems: Base64 is a general binary-to-text encoding, while URL encoding is specifically about making text safe within the URL syntax itself.

Base64 decoding fails if the input isn't valid Base64 — it contains characters outside the Base64 alphabet, or its length doesn't correctly correspond to a whole number of encoded bytes (Base64 encodes data in 4-character groups). URL decoding fails if the input has a stray '%' character not followed by exactly two valid hexadecimal digits, which is the required format for every percent-encoded byte. In both cases, double-check you're pasting the complete, unmodified encoded string — copying only part of an encoded value, or accidentally including extra whitespace or line breaks, is the most common cause of a decoding failure.

HTML encoding here converts the five characters that have special meaning in HTML markup — & (ampersand), < (less than), > (greater than), " (double quote), and ' (single quote) — into their corresponding named or numeric character entities (like &amp; for &). This is the standard, minimal set of characters that must be escaped to safely display arbitrary text as literal content inside HTML without it being misinterpreted as markup — for example, turning a literal `<script>` in user-submitted text into `&lt;script&gt;` so a browser displays it as text instead of executing it. Decoding reverses this, and also understands the wider set of named and numeric HTML entities (like &nbsp; or &copy;) that might appear in real-world HTML content, not just the five it encodes.

A Unicode escape sequence (\uXXXX) represents a single character using its four-digit hexadecimal code point, a format used directly inside JavaScript, JSON, Java, and several other programming languages' string literals — useful when you need to represent a character that's hard to type directly, ensure a string is pure ASCII for compatibility with older systems, or debug exactly which characters are present in a string that looks correct visually but might contain invisible or look-alike Unicode characters. Characters outside the Basic Multilingual Plane (rarer symbols and emoji, mostly) are represented using a pair of escape sequences called a surrogate pair, which this tool handles automatically in both directions.

ROT13 ('rotate by 13') is a simple substitution cipher that shifts every letter 13 positions through the alphabet, wrapping around from Z back to A, while leaving numbers, punctuation, and spacing completely unchanged. Because the English alphabet has exactly 26 letters, applying the same 13-position shift twice returns every letter to its original position (13 + 13 = 26, a full loop) — which is exactly why running ROT13 on already-ROT13'd text decodes it perfectly, with no separate 'decode' operation needed. This makes it a fun novelty cipher, but it provides no real security, since anyone who knows it's ROT13 (or simply tries all 25 possible shifts) can trivially reverse it.

No — neither is encryption, despite sometimes being casually mistaken for it. Both are simple, well-known, publicly documented encodings with no secret key involved: anyone who knows it's Base64 or ROT13 can reverse it instantly using freely available tools (including this one), with no password or cryptographic key required. Base64 is meant purely for safely representing data as text, and ROT13 is a lighthearted novelty cipher historically used to hide spoilers or punchlines in plain sight (so they don't spoil the joke at a glance) rather than to protect genuinely sensitive information. If you need real confidentiality, use actual encryption with a proper cryptographic algorithm and a secret key — never Base64 or ROT13.

Yes — this is one of the most common practical uses. API tokens, JWT segments, and cookie values are frequently Base64-encoded; query parameters and form data are frequently URL-encoded; and log output or config files occasionally contain Unicode-escaped or HTML-escaped text. Pasting a suspicious or unfamiliar encoded value here and decoding it is often the fastest way to see what data it actually represents, without writing a one-off script or opening a separate command-line tool.