Encoding Tools
Base64, URL, and HTML encode/decode utilities.
Encode or decode Base64 for text and files, Unicode-safe.
Percent-encode text for safe use in URLs.
Decode percent-encoded URL text back to plain text.
Escape HTML entities to safely display raw markup as text.
Unescape HTML entities back to raw characters.
Base64, URL encoding, and HTML entity encoding solve three different problems that all happen to look similar — turning one string into another — and mixing them up is one of the most common small bugs in web development. None of them are encryption or obfuscation; all three are fully reversible by design, and treating any of them as a security measure is a mistake this category's tools won't protect you from.
Base64 exists to represent arbitrary binary data (or text with awkward bytes) using only printable ASCII characters — the classic use is embedding an image or a JWT segment inline in text-based formats that can't hold raw binary. The encoder here is Unicode-safe via TextEncoder, which matters because a naive btoa() call in JavaScript throws on non-Latin1 characters; this tool handles UTF-8 input correctly instead of failing on the first emoji or accented character. URL encoding (percent-encoding) exists for a narrower reason: certain characters are reserved in URLs (?, &, #, space) and need escaping so they're not misread as part of the URL's structure rather than as literal data in a query parameter. HTML entity encoding solves a third, unrelated problem — displaying characters that would otherwise be interpreted as markup (<, >, &) safely as visible text in an HTML document.
The bug these three encodings produce when confused is almost always double-encoding: percent-encoding a string that's already percent-encoded turns %20 into %2520, and the same failure mode applies to Base64 and HTML entities. If a round-trip through one of these tools produces a longer, stranger-looking result than you expected, check whether the input was already encoded once before it reached you.
A related mistake is picking the wrong one for the layer you're actually working at. A value going into a query string needs URL encoding regardless of whether it also happens to be Base64 already (a + or / from Base64 output is itself a reserved URL character and needs escaping on top); text being injected into HTML needs entity encoding regardless of what encoding was used to transport it there. Each tool here does exactly one of these three transforms and nothing else — there's no bundled "encode for the web" mode, because which encodings actually apply depends on where in the pipeline the string is headed, and guessing that wrong is worse than making you choose explicitly.