Skip to content

Base64 Encoder / Decoder

Paste text, get Base64. Or the other way around.

Base64 expands data by ~33% (4 chars for every 3 bytes).

How Base64 Encoding Works

Base64 converts binary data into a text-safe format using 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). Every 3 bytes of input become exactly 4 Base64 characters — hence the ~33% size increase. Padding with = signs ensures the output length is always a multiple of 4.

This tool encodes text as UTF-8 bytes first (using the browser's TextEncoder API), then Base64-encodes those bytes. This means it correctly handles accented characters, emoji, Chinese characters, and any other Unicode text — not just ASCII. The URL-safe variant replaces + with -, / with _, and strips the = padding, making the output safe to include in URLs without further encoding.

References

Base64 encoding is formally defined in RFC 4648 — The Base16, Base32, and Base64 Data Encodings (S. Josefsson, October 2006, rfc-editor.org/rfc/rfc4648). Section 4 defines standard Base64, and Section 5 defines the URL-safe alphabet (- and _ replacing + and /). This tool implements both alphabets.

What's here, and what's not

Two-way conversion, URL-safe toggle, UTF-8 correctness (not just ASCII), inline copy buttons for both panes, and a swap button that flips direction and moves the output into the input. The info callout reminds you of the 33% size overhead — useful when deciding whether Base64 is appropriate for your use case.

What isn't here: binary file encoding (drag-and-drop a .jpg and get Base64) is not in v1, that requires FileReader API work and preview rendering. Also absent: Base32, Base16/hex encoding, or streaming for large inputs. Those add enough scope to belong in separate tools.

What is Base64 and When to Use It

Base64 encodes binary data as ASCII text using 64 printable characters (A–Z, a–z, 0–9, +, /). The output is always approximately 33% larger than the input — a necessary tradeoff to make arbitrary binary data safe for text-only channels.

Email attachments (MIME): the original use case. Binary files (images, PDFs) couldn't be transmitted reliably over text-based email protocols — Base64 encodes them as safe ASCII so they survive any mail relay.

Data URIs: embedding images directly in HTML or CSS (<img src="data:image/png;base64,..."/>) eliminates extra HTTP requests. Ideal for small icons and inline images where the round-trip cost exceeds the size overhead.

JWTs (JSON Web Tokens): the header and payload are Base64URL-encoded, the URL-safe variant that replaces + with - and / with _. JWTs are not encrypted; they are only encoded. Anyone can decode them instantly.

API Basic Auth: HTTP Basic Authentication encodes username:password in Base64 and sends it in the Authorization header (Authorization: Basic dXNlcjpwYXNz). This is transport-level convenience, not encryption — always use HTTPS.

Binary data in JSON: JSON cannot represent raw bytes. Base64 bridges the gap for image thumbnails, small files, or binary protocol data that must travel inside a JSON payload.

Related tools: URL Encoder / Decoder, Hash Generator, JWT Decoder, and Number Base Converter.

Base64 is NOT Encryption

Base64 encoding is fully reversible with zero secret key — anyone can decode it in milliseconds. It is obfuscation at best, not security. Never use Base64 to 'hide' sensitive data in a web page, API response, or client-side code. It provides no protection whatsoever.

Base64 vs Base64URL: standard Base64 uses + and /, which are special characters in URLs and can break query strings. Base64URL replaces them with - and _, and omits the = padding. Always use Base64URL for URLs, JWTs, and cookie values.

Common mistake: treating a Base64-encoded JWT as "encrypted". The payload is fully readable to anyone — including the user's browser. Only the signature (HMAC or RSA) ensures integrity; the payload is not confidential. Decode any JWT header and payload in the tool above and see for yourself.

For actual encryption, use AES-256 or RSA — not Base64. Base64 is a transport encoding, not a security primitive.

Frequently Asked Questions

What is Base64 used for?
Base64 is used to safely transmit binary data through text-only channels. Common uses: embedding images in CSS or HTML (data URLs), JWT tokens, Basic Auth headers (username:password → base64), MIME email attachments, and storing binary blobs in JSON or XML.
Why does Base64 increase data size by ~33%?
Base64 encodes every 3 bytes into 4 characters (each character represents 6 bits, 4 × 6 = 24 bits = 3 bytes). So 3 bytes → 4 characters = 4/3 ≈ 1.33× size increase. This overhead is the cost of making binary data printable.
What is the difference between standard and URL-safe Base64?
Standard Base64 (RFC 4648 Section 4) uses + and / as the 62nd and 63rd characters, plus = for padding. These characters have special meaning in URLs. URL-safe Base64 (RFC 4648 Section 5) replaces + with - and / with _ and typically omits = padding. Use URL-safe for JWT tokens, URL parameters, and filenames.
Where is Base64 defined?
RFC 4648 — 'The Base16, Base32, and Base64 Data Encodings' by S. Josefsson (October 2006). Section 4 defines standard Base64 and Section 5 defines the URL-safe alphabet. Available at rfc-editor.org/rfc/rfc4648.
Does this handle emoji and non-ASCII characters?
Yes. The tool uses the browser's TextEncoder API to convert your input to UTF-8 bytes before encoding. On decode, it uses TextDecoder to reconstruct the original string. This correctly handles emoji (🎉), accented letters (é, ü, ñ), Chinese characters, and any Unicode text.
Why is Base64 output always larger than the input?
Base64 encodes every 3 bytes of binary data as 4 ASCII characters — a 4:3 ratio. This makes the output exactly 33.3% larger. Padding characters (=) are added to ensure the output length is a multiple of 4. For small inputs, the overhead is proportionally higher; for large files, it's consistently ~33%. This overhead is unavoidable: it's the cost of encoding 8-bit bytes using only 6-bit characters.
Can I use Base64 to send files via API?
Yes, and it's common for small files (images, PDFs under a few hundred KB). Encode the file as Base64 and include it as a string field in your JSON payload. For large files, prefer multipart/form-data or pre-signed URLs (S3, Azure Blob) — Base64 encoding adds 33% size overhead and increases memory usage in both client and server during processing.

By Bam's Thinkery — Updated