Base64 Encoder/Decoder

Base64 is an encoding method that converts binary data into pure text. It divides the input data into groups of 3 bytes (24 bits), then splits them into 4 6-bit blocks, with each block mapped to a character in the Base64 character table. The 64 characters can be represented by exactly 6 bits (2^6=64), which is the origin of the name "Base64."

The standard Base64 character table includes: uppercase letters A-Z (0-25), lowercase letters a-z (26-51), digits 0-9 (52-61), plus sign + (62), and slash / (63). When the input data length is not a multiple of 3, the end is padded with equals signs =. This encoding method ensures that the output contains only ASCII printable characters and can be safely transmitted in any text protocol.

Standard Base64 (RFC 4648): Uses the A-Za-z0-9+/ character set with = padding. This is the most common variant, used in MIME, PEM certificates, and other scenarios. Most programming languages btoa() / atob() and base64.b64encode() / b64decode() default to this variant.

URL-safe Base64 (Base64URL): Replaces + with - and / with _, and typically omits = padding. This is because + and / have special meanings in URLs (+ represents a space, / is a path separator). The header and payload parts of JWT (JSON Web Token) use Base64URL encoding. There are also some historical variants like the Base64 variant for IMAP, but they are rarely used today.

Base64 encodes byte sequences, not characters. Chinese characters occupy different numbers of bytes under different encodings: one Chinese character takes 3 bytes in UTF-8 and 2 bytes in GBK. Therefore, the same Chinese text encoded with different encodings and then Base64 will produce completely different results.

The most common Chinese garbling issue is inconsistent encoding. For example, if the server encodes Base64 with UTF-8 and the client decodes with GBK, garbled text will result. The best practice is to consistently use UTF-8 encoding. In JavaScript, btoa() only supports Latin1 characters; to handle Chinese, you need to first convert to UTF-8 bytes using TextEncoder. This tool has already handled this issue automatically.

Data URL: Embeds small images directly in HTML or CSS, in the format data:image/png;base64,<encoded data>. This eliminates additional HTTP requests and is suitable for icons smaller than 4KB. However, Base64 increases the data size by about 33%, so it is not recommended for large images.

JWT Authentication: The three parts of a JSON Web Token (header, payload, signature) are all Base64URL encoded and separated by dots. This allows JWT to be transmitted in URLs, HTTP headers, or POST bodies while remaining compact and URL-safe.

The CPU overhead of Base64 encoding and decoding is almost negligible on modern devices; the main cost is the 33% increase in data size. For HTTP transmission, this means more bandwidth consumption. If gzip compression is enabled, Base64 data typically has a lower compression ratio than raw binary data.

On mobile devices, large amounts of Base64-encoded images consume more memory. A 1MB image becomes about 1.33MB after Base64 encoding, and with the memory overhead of JavaScript strings, the actual memory usage can reach 2-3MB. Therefore, large files should preferentially use binary transmission (such as multipart/form-data), with Base64 used only when necessary.

Base64 is not encryption! This is a common misconception. Base64-encoded data can be instantly decoded by anyone and provides no confidentiality protection. Base64-encoding sensitive information (such as passwords, API keys) and calling it "encryption" is a serious security vulnerability.

The correct use of Base64 is "transport encoding," not "security encoding." If you need to protect data confidentiality, use encryption algorithms such as AES-256-GCM. If you need to prevent tampering, use HMAC signatures. Base64 can be used in conjunction with encryption - first encrypt to get binary ciphertext, then Base64-encode it into text format for transmission.