Base64 Converter

How to Use This Calculator

1. Type or paste your text into the input field.
2. The Base64 encoded output appears instantly.
3. Use Base64 → Text tab to decode Base64 back to the original string.
4. Use URL-Safe Base64 tab for encoding destined for URLs, JWTs, or query parameters.
5. Professional tab explains padding (=), size overhead, and Base64 vs Base32 vs Base85 comparison.

Formula

Example

Frequently Asked Questions

• What is Base64 encoding and when do I need it? ▼
  Base64 is an encoding scheme that converts binary data into a string of 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). It was developed because many transport protocols — email (SMTP), HTTP headers, URLs, and XML/JSON payloads — were designed for text and cannot reliably handle arbitrary binary bytes. Base64 lets you embed images, certificates, cryptographic keys, and file attachments in text-only contexts. Common uses include: encoding images as data URIs in CSS/HTML (data:image/png;base64,...), embedding X.509 certificates in PEM files (the -----BEGIN CERTIFICATE----- blocks are Base64), encoding binary fields in JSON APIs, encoding Basic Auth credentials in HTTP headers (username:password → Base64), and storing binary data in cookies. Base64 is also used in JWT (JSON Web Tokens) to encode the header and payload sections. You need Base64 whenever you must represent binary data in a text-safe format.
• Is Base64 the same as encryption? ▼
  No — Base64 is encoding, not encryption. This distinction is critical and commonly misunderstood. Encoding is a reversible transformation with no secret key: anyone who sees Base64 data can decode it instantly. Encryption requires a secret key and is computationally infeasible to reverse without it. Base64 provides zero confidentiality — it is trivially decoded by any Base64 decoder. Sending sensitive data "encoded in Base64" over HTTP is no safer than sending it in plaintext. The confusion arises because Base64 output looks scrambled and unreadable to humans, creating a false sense of security. If you need to protect data in transit, use TLS/HTTPS encryption. If you need to protect stored data, use authenticated encryption like AES-GCM. Base64 should be used only to solve text-compatibility problems, never as a security measure. Seeing Base64 in a security context usually means it is wrapping already-encrypted or signed data.
• Why does Base64 make data 33% larger? ▼
  Base64 uses 64 characters to represent data, and 64 = 2⁶, meaning each Base64 character carries exactly 6 bits of information. However, ASCII characters use 8 bits each. So 8-bit bytes are re-encoded as 6-bit groups: every 3 bytes (24 bits) of input become 4 Base64 characters (24 ÷ 6 = 4). The size increase is 4/3 ≈ 1.333, or exactly 33% larger. If the input length is not divisible by 3, padding characters (=) are appended to complete the final 4-character block — one = if the input has 2 leftover bytes, two == if it has 1 leftover byte. This overhead is the price of text compatibility. Base85 (RFC 1924) achieves better density — 5 bytes per group rather than 3 — giving only ~25% overhead, but it requires a larger character set. For contexts where size matters more than compatibility, binary protocols or compression before Base64 can reduce overhead.
• What is the difference between standard Base64 and URL-safe Base64? ▼
  Standard Base64 uses the characters A–Z, a–z, 0–9, plus (+) and slash (/). The problem is that + and / are special characters in URLs: + means space in query strings, and / is a path separator. If you put standard Base64 in a URL query parameter or path segment without encoding, the + becomes a space and / breaks the URL structure. URL-safe Base64 (defined in RFC 4648 Section 5) solves this by replacing + with hyphen (-) and / with underscore (_). These characters are URL-safe without percent-encoding. Padding characters (=) are also sometimes omitted in URL-safe contexts since = is also a special character in URLs. JWT (JSON Web Tokens) use URL-safe Base64 without padding to encode their header and payload. When working with APIs, OAuth tokens, or anything embedded in URLs, always use URL-safe Base64. Standard Base64 is correct for email attachments, PEM files, and data URIs.
• Can I encode any binary data with Base64? ▼
  Yes — Base64 can encode any binary data whatsoever: images, audio files, executables, encrypted ciphertext, compressed archives, PDFs, or any sequence of bytes. The encoding is purely mechanical — each group of 3 bytes is converted to 4 ASCII characters with no interpretation of the content. This universality is precisely why Base64 is so widely used: it makes any binary payload safe to embed in text contexts like JSON, XML, HTML, email, and HTTP headers. The decoder reconstructs the original bytes exactly, with no loss of information. The only limitations are practical: very large files encoded in Base64 become 33% larger and must be held in memory as strings, which can be inefficient. For large files, streaming Base64 encoding/decoding is preferred over loading the entire file at once. Modern browsers support btoa() and atob() functions for Base64, and Node.js provides Buffer.from(data).toString("base64") for server-side encoding.

Related Calculators