Encode and decode plain text or binary to Base64 with charset support.
How arbitrary binary streams are safely packaged into printable ASCII text for internet transport.
Standard binary bytes contain 8 bits. Base64 divides a stream of bytes into 6-bit chunks (2^6 = 64 discrete values: A-Z, a-z, 0-9, "+" and "/"). Every 3 input bytes (24 bits) produce exactly 4 Base64 characters. This introduces an intentional 33.3% size overhead to guarantee that binary payloads such as images, keys and signatures pass reliably through text-based protocols like JSON, HTTP headers and SMTP email without control-character corruption.
When the input byte stream is not evenly divisible by 3, the trailing block is zero-padded and filled with "=" characters indicating dummy byte positions: one "=" for a 2-byte remainder, two "=" for a 1-byte remainder. While modern permissive parsers accept unpadded Base64, strict RFC 4648 parsers require full padding.
Standard Base64 assigns "+" and "/" to table indexes 62 and 63. In HTTP URLs or filesystem paths, these symbols collide with reserved delimiters. RFC 4648 Section 5 defines URL and filename safe Base64, replacing "+" with "-" and "/" with "_", allowing clean embedding into URL query strings and JWT authentication headers.
No. Base64 is strictly a representation format that allows binary transmission across ASCII-only protocols. It provides zero cryptographic secrecy or protection.
Because 24 bits of source information are stored across 32 bits of ASCII text characters. The mathematical expansion ratio is exactly 4 to 3, a 33.3% overhead plus optional padding.
Use it to inline small assets such as CSS icons or MIME attachments, and to move binaries through text-only channels. Avoid it for large files: the 33% overhead and the inability to stream make it less efficient than a direct binary upload.