Base64 Encoder / Decoder

How to Use the Base64 Encoder / Decoder

Select your desired mode using the Encode or Decode toggle buttons at the top of the tool. In Encode mode, type or paste any plain text into the input area — including Unicode characters, emojis, and special symbols. Click the "Encode to Base64" button to convert your text into a Base64-encoded string. In Decode mode, paste a valid Base64 string and click "Decode from Base64" to retrieve the original text.

The output appears below the tool in a highlighted area. Use the Copy button to instantly copy the result to your clipboard. The character count for both input and output updates automatically so you can track string lengths. This tool processes everything locally in your browser — no data is transmitted to any server, making it safe for encoding sensitive content like API keys or authentication tokens.

If you receive an error during decoding, ensure your input is valid Base64 — it should only contain characters A-Z, a-z, 0-9, +, /, and optional = padding at the end. Whitespace and line breaks in the input may cause decoding errors. Remove any extra spaces or newlines before decoding for best results.

Formula / Method

Base64 encoding converts binary data into a text format using 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). The algorithm takes every 3 bytes (24 bits) of input and splits them into four 6-bit groups. Each 6-bit value maps to a character in the Base64 alphabet. If the input length is not divisible by 3, padding characters (=) are added to complete the final group.

For UTF-8 text, the process first converts Unicode characters into their multi-byte UTF-8 representation using a TextEncoder, then applies Base64 encoding to the resulting bytes. This ensures that non-ASCII characters like 'ñ', 'ü', Chinese characters, and emojis are handled correctly without data loss. Standard btoa() only handles single-byte characters, so the UTF-8 pre-processing step is essential for international text.

The encoding ratio is always 4:3 — every 3 input bytes produce exactly 4 output characters. This means Base64-encoded data is approximately 33% larger than the original binary data. Decoding reverses the process: each Base64 character is mapped back to its 6-bit value, groups of four are combined into three bytes, and the bytes are decoded back to UTF-8 text.

Example

Input text: "Hello, World!"

Step 1: Convert to bytes → [72, 101, 108, 108, 111, 44, 32, 87, 111, 114, 108, 100, 33]

Step 2: Group into 3-byte blocks → [72,101,108] [108,111,44] [32,87,111] [114,108,100] [33]

Step 3: Convert each block to four 6-bit indices → For [72,101,108]: binary is 010010000110010101101100, split into 010010 000110 010101 101100 = indices 18, 6, 21, 44 = "SGVs"

Step 4: Concatenate all groups → "SGVs" + "bG8s" + "IFdv" + "cmxk" + "IQ=="

Final output: "SGVsbG8sIFdvcmxkIQ=="

The last group "IQ==" has two padding characters because only 1 byte (33 for '!') remained in the final block, requiring 2 padding characters to complete the 4-character output group.

UTF-8 example: The text "café" encodes to "Y2Fmw6k=" because the 'é' character uses two bytes (0xC3, 0xA9) in UTF-8 encoding, demonstrating why proper UTF-8 handling is necessary for international text.

Reference Table

Frequently Asked Questions

Related Calculators

Understanding Base64 Encoding in Depth

Base64 encoding was originally designed for the Multipurpose Internet Mail Extensions (MIME) standard to safely transmit binary attachments through email systems that only support 7-bit ASCII text. The encoding uses a specific alphabet of 64 characters chosen because they are universally safe across different character sets and transfer protocols. The standard Base64 alphabet consists of uppercase letters (A-Z, values 0-25), lowercase letters (a-z, values 26-51), digits (0-9, values 52-61), plus sign (+, value 62), and forward slash (/, value 63).

There are several variants of Base64 encoding for different use cases. URL-safe Base64 replaces + with - and / with _ to avoid conflicts with URL syntax. MIME Base64 inserts line breaks every 76 characters for email compatibility. The base64url variant defined in RFC 4648 is commonly used in JSON Web Tokens (JWT), where the encoded payload must be URL-safe without additional percent-encoding. Understanding which variant you need is critical when working with different APIs and protocols.

In web development, Base64 encoding is frequently used for data URIs that embed small images, fonts, or other assets directly in HTML or CSS files. This eliminates additional HTTP requests at the cost of increased file size. For images under 2-3 KB, the trade-off usually favors inline Base64 encoding because the overhead of a separate HTTP request often exceeds the 33% size increase from encoding. CSS sprites and icon fonts have been largely replaced by SVG and Base64 data URIs in modern web development.

JavaScript provides native Base64 functions: btoa() encodes a binary string to Base64, and atob() decodes Base64 back to a binary string. However, these functions only handle characters in the Latin-1 range (code points 0-255). For full Unicode support, you must first encode the text as UTF-8 bytes using TextEncoder, then convert those bytes to a binary string before calling btoa(). This tool handles this conversion automatically, ensuring that text in any language encodes and decodes correctly.

Base64 is also essential in API development. HTTP Basic Authentication concatenates username and password with a colon separator, then Base64-encodes the result for the Authorization header. While this provides no security on its own (always use HTTPS), it ensures special characters in credentials don't break the HTTP header format. Similarly, OAuth tokens and JWTs use Base64url encoding for their header and payload sections, making them URL-safe while remaining human-inspectable.

When working with binary files like images or PDFs, Base64 encoding allows you to include the file content directly in JSON payloads, database text columns, or configuration files. Many APIs accept Base64-encoded file uploads as an alternative to multipart form data. The trade-off is increased payload size and processing overhead versus simpler request structure. Cloud storage services often use Base64 for content hashes and integrity verification.

Performance considerations matter when encoding large files. While Base64 encoding and decoding are computationally fast operations, the 33% size increase means more data transmitted over the network and more memory consumed. For files larger than a few kilobytes, it's generally better to use binary transfer methods like multipart uploads rather than Base64 encoding. This tool works best for encoding text, small files, or verifying Base64 output during development and debugging workflows.

Common debugging scenarios where Base64 is useful include inspecting JWT tokens (which have three Base64url-encoded segments separated by dots), decoding email attachments, examining data URIs, and verifying API request bodies. Developers frequently need to quickly encode or decode Base64 strings during API development, testing, and troubleshooting, making this tool an essential part of any web developer's toolkit.

Security note: Base64 is not encryption and provides zero confidentiality. Any encoded string can be trivially decoded by anyone. Never rely on Base64 to hide sensitive information — always use proper encryption (AES-256, RSA) for data that needs protection. Base64 is purely a data representation format, useful for safe transport of binary data through text-only channels, not for securing that data against unauthorized access.

In database applications, Base64 encoding allows storing binary data (images, files, serialized objects) in text columns without worrying about character encoding issues or null byte handling. However, the 33% overhead means increased storage costs. Modern databases with native BLOB/BYTEA types are preferable for large binary data, while Base64 text columns work well for small payloads like cryptographic hashes, thumbnail images, or configuration snippets that need to be human-readable in query results.