Base64 Encoder / Decoder

Base64 encoding converts data into a string of plain text characters (A-Z, a-z, 0-9, plus + and /) that can safely pass through systems designed to handle text but not raw binary, like email bodies, JSON payloads, or URL query parameters. This tool encodes any text you type or paste into its Base64 representation, and decodes a Base64 string back to its original text, entirely in your browser.

It's built for developers working with APIs that expect Base64-encoded fields, anyone decoding a Base64 string they found in a config file or JWT token, or anyone needing to safely embed short text inside a system that would otherwise choke on special characters. This tool works on typed or pasted text, not on uploaded files.

Type or paste your content into the box, click Encode or Decode, and copy the result. Everything happens locally in your browser using the standard btoa and atob functions, so nothing you enter is transmitted anywhere.

Base64 works by taking 3 bytes (24 bits) of original data and re-encoding them as 4 characters, each representing 6 bits, drawn from a 64-character alphabet. Because 4 output characters always replace 3 input bytes, every Base64-encoded string ends up about 33% larger than the original data it represents, a fixed ratio that holds regardless of what's being encoded.

This size increase is the tradeoff for compatibility: Base64's 64-character alphabet only uses letters, digits, and two symbols, all of which are safe to transmit through systems built for plain ASCII text, like older email protocols that couldn't reliably carry raw binary data. The extra size is a small price for guaranteed compatibility across systems that would otherwise corrupt or reject non-text content.

For example, the 11-character text 'Hello World' encodes to 'SGVsbG8gV29ybGQ=' at 16 characters, roughly a 45% increase for this short example (the exact percentage varies slightly for very short strings due to padding). Longer inputs converge closer to the standard 33% overhead.

• 3 bytes of input become 4 characters of Base64 output
• Fixed overhead: encoded output is roughly 33% larger than the original
• Alphabet: A-Z, a-z, 0-9, plus '+' and '/' (with '=' used for padding)
• Not compression — Base64 always increases size, it never reduces it

Base64 is encoding, not encryption, and it provides zero confidentiality. Anyone who sees a Base64 string can decode it back to the original text in seconds using this tool, a browser console, or a one-line command, with no password or key required. If you see a Base64 string and want to know what it says, decode it here; there's no security barrier to overcome.

This matters because some systems mistakenly present Base64-encoded values, like an API key or a config setting, as though they're protected. They aren't. Base64 exists purely to make binary-safe data pass safely through text-only channels; if you need actual confidentiality, that requires real encryption with a secret key, not encoding.

One common use of Base64 is embedding a small image directly inside HTML or CSS as a data URI, avoiding a separate network request for a tiny icon or background image. A data URI looks like data:image/png;base64, followed by the Base64-encoded image bytes, and browsers render it exactly like a normal externally-linked image.

This trick works best for small, frequently reused assets, like a favicon-sized icon or a simple SVG, since the 33% size overhead and the fact that the encoded string can't be cached separately from the page mean it's a poor fit for large photos or images used across many pages. This text-based tool handles the text side of that workflow (encoding a snippet or decoding a data URI's Base64 portion back to inspect it), though converting binary image files to Base64 typically requires an image-specific converter or a short script.

Base64 appears constantly once you know to look for it: the middle segment of a JWT (JSON Web Token) is Base64-encoded JSON, email attachments are Base64-encoded inside the MIME message format, and HTTP Basic Authentication sends credentials as a Base64-encoded 'username:password' string in a request header.

In every one of these cases, decoding reveals plain, readable text; none of them rely on Base64 for security. A JWT's payload can be decoded and read by anyone who has the token, which is exactly why sensitive data shouldn't be put directly into a JWT payload without additional encryption, and why HTTP Basic Auth should only ever be used over an HTTPS connection.

• JWT tokens: header and payload segments are Base64-encoded JSON
• Email (MIME): attachments are Base64-encoded to survive text-only transport
• HTTP Basic Authentication: credentials sent as a Base64-encoded string in a header
• Data URIs: small images and fonts embedded directly in HTML or CSS

The most frequent decoding error comes from a truncated or partially copied Base64 string, since a valid string's length must be a multiple of 4 (padded with = characters if needed); pasting only part of a longer string produces an invalid-string error rather than garbled output. Double-check that you copied the complete value, including any trailing = padding characters.

Another common issue is URL-safe Base64, a variant that replaces the standard + and / characters with - and _ to avoid conflicting with URL syntax. This tool expects standard Base64; a URL-safe string will need those characters swapped back before it decodes correctly here.