Base64 Encoder & Decoder

Convert text and images to Base64 format and vice versa. All processing happens locally in your browser.

🖼️

Click to upload or drag & drop an image

You can also paste an image (Ctrl+V / Cmd+V)

About Base64 Encoder

Base64 is a binary-to-text encoding scheme defined in RFC 4648 that converts arbitrary binary data into a string of 64 printable ASCII characters. The encoding works by taking the input data in 3-byte (24-bit) chunks, splitting each chunk into four 6-bit groups, and mapping each group to one of 64 characters: uppercase letters A-Z (0-25), lowercase letters a-z (26-51), digits 0-9 (52-61), plus (+, 62), and slash (/, 63). If the input length is not divisible by 3, one or two padding characters (=) are appended to maintain the 4-character output alignment. This 33% size overhead is the trade-off for representing binary data in environments that only support text, such as JSON payloads, URL parameters, email bodies, and HTML attributes.

Our Base64 Encoder supports two primary workflows: text encoding/decoding and image-to-Base64 conversion. For text, we use the modern TextEncoder API to properly handle Unicode characters (including emoji and non-Latin scripts), eliminating the historical unescape(encodeURIComponent()) workaround that was necessary before TextEncoder became universally available. For images, the tool generates both the raw Base64 string and the complete Data URL (including the MIME type prefix), ready for direct embedding in HTML <img> tags or CSS background-image properties. All processing happens locally in your browser via the FileReader API — your files and text never leave your device.

Base64 vs Other Encoding Schemes

  • Base64: 33% overhead, URL-safe variant available, supports binary data, readable in text editors
  • Hex (Base16): 100% overhead (2 chars per byte), simplest to implement, commonly used in cryptographic hashes
  • URL Encoding: Variable overhead, designed for URL parameters, does not handle binary data natively
  • Base32: 60% overhead, case-insensitive, used in OTP (one-time password) shared secrets

Real-World Applications

  • Data URLs: Embed small images (icons, logos, avatars) directly in HTML/CSS to eliminate HTTP requests and improve page load speed
  • JSON Web Tokens (JWT): Encode header and payload claims in the compact JWT format used by OAuth 2.0 and modern authentication systems
  • Email MIME: Encode binary attachments (PDFs, images, documents) within the text body of SMTP email messages
  • API Payloads: Transmit binary data (audio, images, files) inside JSON API requests where raw binary is not supported
  • Configuration Files: Store certificates, keys, and small assets inline in YAML, JSON, or XML configuration files
  • Steganography: Hide binary data within text fields, QR codes, or other text-based media

Important Security Notes

  • Base64 is not encryption — it is merely encoding. Anyone can decode a Base64 string instantly. Never use it to protect sensitive data.
  • Base64-encoded data is approximately 33% larger than the original binary. For large files, consider direct binary transfer or compression before encoding.
  • Data URLs embedded in HTML can bloat page size significantly. Use them only for very small assets (under 2-3KB) and prefer external files for larger images.
  • When decoding Base64 text containing Unicode characters, ensure the correct character encoding (typically UTF-8) is used to avoid garbled output.

Frequently Asked Questions

Is Base64 encryption?

No. Base64 is an encoding, not an encryption; anyone can decode a Base64 string back to the original data in a fraction of a second without a key. Never use Base64 to hide secrets; use a real encryption scheme (AES-256-GCM, ChaCha20-Poly1305, libsodium secretbox) for that. Base64's purpose is to convert binary data into a text-safe representation that survives transport through text-only channels like email, JSON, and URLs.

What's the size overhead of Base64?

Base64 inflates the input by roughly 33% (3 input bytes become 4 output characters). A 100 KB image becomes a ~133 KB data URL. For most web uses, this is acceptable; for very large assets, prefer a direct file URL over a data URL. Most email systems impose a 76-character line length on Base64, which adds further padding overhead if you need to wrap long strings.

Does my data leave the browser?

No. Encoding and decoding both run client-side using the browser's btoa, atob, and TextEncoder APIs. We do not have a server-side Base64 processor, and the page makes no network calls with your content. It is safe to encode confidential text or sensitive image bytes here.

When should I use Base64 vs. a real file?

Use Base64 (data URLs) when the asset is tiny (under 2–3 KB), needs to be inlined for a self-contained artifact (a single HTML file, a CSS rule, an email signature), or when you cannot rely on the destination to host the file. For larger assets, use a real file URL: data URLs are not cached separately from the containing document, cannot be lazy-loaded, and bloat the parent document.