Base64 Encoder.

Base64 is one of those encoding schemes that quietly underpins a huge portion of the internet — from the images in your email newsletter to the authentication token in your app's HTTP header. Understanding it is essential for any web developer, and having a reliable, private encoder/decoder is a daily tool in the developer toolkit.

The Four Modes Explained

Text ⇌ Base64 is the most common mode. It handles full Unicode text correctly — including Hindi (Devanagari), Tamil, emoji, and CJK characters — using TextEncoder for UTF-8 encoding before btoa(). The Flip button swaps input and output, letting you round-trip data without copy-pasting. Input and output sizes are shown in bytes, and the size ratio is displayed so you can see the overhead of encoding.

File → Base64 reads any local file using the browser's FileReader API and outputs both the raw Base64 string and the complete data URL (data:[mimeType];base64,[data]). This is the fastest way to get a data URL for a CSS background image, an email-embedded image, or a self-contained HTML attachment.

Image Preview takes a Base64 string or data URL and renders it visually, letting you verify the image before using it in production. This is invaluable when debugging Base64 images that aren't displaying correctly — you can immediately see whether the encoding is valid or if there is a MIME type mismatch.

URL-Safe Base64 produces output compatible with URLs, filenames, and JWT tokens by substituting the two problematic characters: + becomes - (hyphen) and / becomes _ (underscore), and padding = is stripped. This is the format specified in RFC 4648 §5 and used by OAuth 2.0, PKCE code challenges, and all modern JWT implementations.

Base64 in Web Development

The most common use case developers encounter is embedding small assets — icons, logos, loading spinners — directly in CSS or HTML as data URLs. This trades file size (the 33% Base64 overhead) for reduced HTTP requests. For small files below about 2 KB, the tradeoff is usually worthwhile, especially for critical above-the-fold assets. For larger assets, a cached HTTP request is almost always more efficient.

Font embedding is another powerful use case. Embedding a subset of a custom font in your CSS eliminates the FOUT (Flash of Unstyled Text) on first load. Use File → Base64 mode, encode your .woff2 file, and construct the @font-face rule with the data URL as the source. This approach is particularly useful for email templates where linked font URLs are often blocked by email clients.

Base64 vs Encryption: A Critical Distinction

A very common misconception is that Base64-encoded data is "hidden" or "secure." It is not — at all. Base64 is purely a representational format. Any tool, including this one, can decode Base64 instantly with no key or secret. If you need to protect data, use real encryption: AES-256 for symmetric encryption or RSA/ECDH for asymmetric. Base64 is often used alongside encryption (e.g., the ciphertext might be Base64-encoded for transmission), but the encoding itself contributes zero security.

This matters in practice: never Base64-encode passwords, API keys, or sensitive personal data and assume they are safe. HTTPS protects data in transit, but if Base64-encoded credentials are stored in browser localStorage, cookies, or source code, they are trivially extractable.

Unicode and Charset Handling

JavaScript's built-in btoa() function only accepts "binary strings" — strings where each character's code point is between 0 and 255. Passing a Unicode string with characters above U+00FF (like most Indian scripts, CJK characters, or emoji) directly to btoa() throws an InvalidCharacterError. Our tool handles this correctly by first encoding the text to UTF-8 bytes using TextEncoder, then passing the resulting byte string to btoa(). The reverse decoding uses TextDecoder for clean UTF-8 interpretation.