Base64 Encoder

How to encode text to Base64

1. Paste any text into the input field — plain text, JSON, XML, credentials, or any Unicode content including emoji.
2. Click "Convert" — the Base64-encoded string appears instantly in the output panel.
3. Switch to "Decode" using the toggle above if you need to decode Base64 back to text.
4. Click "Copy" to copy the encoded string, or "Download .txt" to save the file.
5. Use the output in a URL, HTTP header, data URI, JWT token, or any context that requires ASCII-safe encoding.

How Base64 encoding works

Base64 encoding converts arbitrary binary data into a string of 64 printable ASCII characters. The encoder reads input 3 bytes at a time, splits each group into four 6-bit values, and maps each value to a character from the Base64 alphabet (A–Z, a–z, 0–9, +, /). If the input length is not divisible by 3, one or two = padding characters are appended to make the output length a multiple of 4.

This converter uses the browser's TextEncoder API to handle full Unicode input — including emoji, CJK characters, Arabic, and Cyrillic — by encoding the text to UTF-8 bytes first, then encoding those bytes to Base64. This is the correct approach for multilingual text; using btoa() directly on Unicode strings throws an error for any character with a code point above 127.

// The converter uses TextEncoder for proper Unicode support:
function base64Encode(text) {
  const bytes  = new TextEncoder().encode(text)
  const binary = Array.from(bytes, b => String.fromCharCode(b)).join('')
  return btoa(binary)  // standard Base64
}

base64Encode('Hello, World!')  // → 'SGVsbG8sIFdvcmxkIQ=='
base64Encode('Привіт, світ!') // → correctly encoded (TextEncoder handles UTF-8)
base64Encode('Hello 🌍')       // → 'SGVsbG8g8J+MjQ=='

// btoa() alone throws for non-ASCII input:
btoa('Привіт')  // ❌ InvalidCharacterError

Who uses Base64 encoding

Base64 is used whenever binary or arbitrary text data needs to be transmitted or stored in a context that only supports ASCII-safe characters — URLs, HTTP headers, email bodies, HTML attributes, and configuration files.

• API authentication — HTTP Basic Auth encodes credentials as Base64: Authorization: Basic base64(username:password). Every API using Basic Auth generates and decodes these strings.
• JWT tokens — the header and payload sections of a JSON Web Token are Base64URL-encoded. Inspecting the claims inside a JWT requires decoding these sections.
• Data URIs — embedding images, fonts, or SVGs directly in HTML or CSS as data:image/png;base64,... avoids additional HTTP requests.
• Environment variables — storing binary config (TLS certificates, private keys) in environment variables that only accept text strings.
• Email attachments — MIME encoding uses Base64 to transmit binary file attachments through email protocols that only support 7-bit ASCII.
• Webhook payloads — some platforms encode event data in Base64 before including it in a JSON payload to ensure safe transmission.

Base64 alphabet, output size, and variants

The standard Base64 alphabet uses 65 characters: 64 data characters plus = for padding. Base64URL (used in JWTs and URL parameters) replaces + with - and / with _ to avoid conflicts with URL-reserved characters.

Output size: every 3 bytes of input produce 4 Base64 characters. The encoded output is always 4/3 × the input byte length, rounded up to the nearest multiple of 4. "Hello" (5 bytes) encodes to "SGVsbG8=" (8 characters — a 60% size increase). Base64 encoding always makes data larger, never smaller.

When to use Base64 — and when not to

Use Base64 encoding when:

• The transport channel is ASCII-only — email (SMTP), HTTP headers, URL query parameters, and some older protocols only support 7-bit ASCII characters.
• Embedding binary data in text formats — including images or fonts in CSS/HTML as data URIs, or embedding file contents in JSON or XML payloads.
• Storing binary data in text fields — database columns, environment variables, or config files that cannot hold raw binary bytes.
• Protocol requirements specify it — HTTP Basic Auth, JWT, and MIME email attachments all require Base64 encoding by specification.

Do NOT use Base64 when:

• You think it provides security — Base64 is not encryption. Anyone can decode it instantly. Sensitive data encoded in Base64 is just as exposed as plain text.
• You want to compress data — Base64 expands output by ~33%. Use gzip or Brotli if you want smaller output.
• The transport already handles binary — modern HTTP APIs, WebSockets, and multipart form uploads do not require Base64 for binary payloads.
• You're hiding passwords or tokens — encoding a secret in Base64 and committing it to source code is not more secure than plain text. Use a secrets manager.

Common Base64 patterns you'll encounter

Once you recognize the Base64 pattern — blocks of letters, digits, + and /, ending with 0–2 = signs — you'll start noticing it in many places. The examples below show where Base64 appears in everyday web development.

// HTTP Basic Auth header (username:password encoded):
Authorization: Basic dXNlcjpwYXNzd29yZA==
// Decoded: user:password

// JWT token (three Base64URL sections separated by dots):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header (Base64URL)
.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFsaWNlIn0  ← payload (Base64URL)
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  ← signature (binary)

// CSS data URI (SVG image embedded directly):
background-image: url(data:image/svg+xml;base64,PHN2Zy4uLj4=)

// HTML img tag with Base64 encoded image:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />