🔁 Base64 & URL Encoder/Decoder
Works entirely in your browser — no data is sent to any server.
Why Base64, URL Encoding, and HTML Entities Still Matter in 2024
Open any browser's developer tools and start poking around network requests. Within minutes you'll run into something like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 sitting in an Authorization header, or a URL that looks like https://example.com/search?q=hello%20world%20%26%20more. These aren't random gibberish — they're encoded data, and knowing how to decode them quickly is a genuine superpower for developers, security researchers, and anyone who wants to understand what's actually flowing through their applications.
Base64, URL encoding, and HTML entities each solve a specific problem that arises when you need to move arbitrary data through channels that weren't designed for it. Getting them confused — or worse, misusing them as security measures — leads to bugs that can be surprisingly painful to diagnose.
Base64: Moving Binary Through Text Channels
Base64 was designed in the early days of email when SMTP could only reliably transport 7-bit ASCII text. If you needed to attach a PDF or an image, you had to transform those binary bytes into a form that ASCII-safe protocols wouldn't corrupt. The encoding takes every three bytes of input, splits them into four 6-bit groups, and maps each group to one of 64 safe characters (A–Z, a–z, 0–9, +, and /). The = padding at the end brings the output length to a multiple of four.
The math means Base64 output is always about 33% larger than the input — a 100-byte file becomes roughly 136 bytes of Base64. That's the price you pay for portability. For small payloads like auth tokens, the tradeoff is completely worth it. For transferring large binary files, you'd want something else.
One thing that trips people up is the URL-safe variant. Standard Base64 uses + and /, both of which are special characters in URLs. The URL-safe variant (sometimes called Base64url) swaps these for - and _, and often strips the trailing = padding. This is what JWTs use — the header and payload sections of a JSON Web Token are Base64url-encoded, which is why you can decode them with any Base64 tool if you handle the character substitution and optional padding. Try pasting a JWT into this tool set to "Base64 URL-safe" mode — you'll see the header decode to something like {"alg":"HS256","typ":"JWT"} immediately.
Data URIs and When You'll Actually Encounter Base64
Beyond auth tokens, Base64 shows up in a few other places that are worth recognizing on sight. Data URIs embed file content directly into HTML or CSS: data:image/png;base64,iVBORw0KGgo... — that long string after the comma is the PNG file's bytes, Base64-encoded. Inline SVG icons in build tool output often use this technique. Email clients send attachments encoded this way. Some APIs accept file uploads as Base64 strings in JSON bodies rather than multipart form data.
When you're debugging a CSP (Content Security Policy) violation or an email rendering issue, being able to instantly decode an inline data URI can save you from a lot of guesswork.
URL Encoding: Two Flavors, One Common Confusion
There's a distinction that many developers never fully internalize: encodeURI() and encodeURIComponent() are not the same thing, and using the wrong one is a genuine source of bugs.
encodeURI() assumes you're encoding a complete URL. It leaves structural characters alone — things like /, ?, #, &, = — because those are part of URL syntax. It only encodes characters that can't appear in a URL at all, like spaces (becoming %20) and non-ASCII characters.
encodeURIComponent() assumes you're encoding a single value that will go inside a URL, like a query parameter value. It encodes everything that could be misinterpreted as URL structure, including &, =, +, #, and forward slashes. If your query parameter contains another URL or a JSON object, you need encodeURIComponent, or the receiving server will misparse your request.
A classic bug: someone builds a redirect URL by doing encodeURI('https://example.com/return?url=https://other.com/page'). The inner ?url= part doesn't get encoded, so when the server parses the outer URL, it sees two query parameters instead of one. The correct approach is to encodeURIComponent just the inner URL, then embed it as a value.
Percent-encoding also appears in form submissions. When a browser submits an HTML form with method="GET", it URL-encodes the field values. Spaces become + (not %20) in this context — an older convention from the application/x-www-form-urlencoded format. This tool handles both conventions when decoding.
HTML Entities: More Than Just &
HTML entity encoding is what stands between your users' text content and XSS attacks. The five characters that must be escaped in HTML are < (<), > (>), & (&), " ("), and ' ('). When you're inserting user-supplied text into an HTML page, failing to escape even one of these can let an attacker inject arbitrary markup — the classic XSS scenario.
Modern template engines and frameworks do this automatically, which is why hand-rolling HTML string concatenation is so dangerous. But when you're working with raw API responses, legacy code, or email templates, knowing what the encoded forms look like helps you verify that escaping is actually happening.
Beyond the critical five, HTML supports hundreds of named entities ( , —, ©) and numeric references like — (em dash) or — in hex. These are useful when you need to include specific Unicode characters in contexts where direct character input is unreliable — older CMS platforms, certain email clients, and XML documents where character encoding declarations might be missing or wrong.
Security Notes: What These Encodings Are Not
This is worth saying plainly because the confusion causes real vulnerabilities: Base64 is not encryption. It is not obfuscation that provides any security. Anyone can decode it in seconds. If you see a system that "protects" sensitive data by Base64-encoding it, that's a red flag. The data is effectively in plaintext.
Similarly, URL-encoding and HTML entities are not sanitization for SQL queries or shell commands. They solve specific injection problems in specific contexts (HTML and URLs respectively), not general-purpose injection. Passing HTML-encoded input to a database query does nothing to prevent SQL injection.
Where these encodings genuinely help security is in payload inspection. When you're analyzing a suspicious email, a malware sample, or an obfuscated script, Base64 decoding is often the first step in peeling back layers. Phishing kits and web shells frequently use multiple rounds of encoding — sometimes Base64 inside Base64 inside URL encoding — to evade naive pattern matching. Using a tool like this to manually trace through the layers gives you the actual payload without executing anything.
Practical Workflow Tips
When decoding something of unknown origin, always decode into this tool's output area and read it before doing anything else with it. Never paste an unknown decoded value into a browser URL bar or a terminal without inspecting it first — decoded content might be another payload, not a human-readable string.
JWT debugging is one of the most common use cases. The three dot-separated sections of a JWT decode as: Base64url header, Base64url payload, and a signature you cannot verify without the secret key. The signature section will look like random bytes — that's expected. Focus on the header (algorithm type) and payload (claims, expiry) which are plain JSON once decoded.
For inspecting query strings from log files, URL-decoding the entire line first often makes the parameters immediately readable, saving the mental overhead of translating %2F, %3A, and similar sequences on the fly.