Base64 encode and decode
Choose standard Base64 or the URL-safe alphabet. Processing happens on this web server, so do not paste passwords, private keys, access tokens or other secrets into a public online tool.
What Base64 is
Base64 is a binary-to-text encoding. It takes groups of input bits and represents them with a restricted text alphabet. Standard Base64 uses A–Z, a–z, 0–9, + and /, with = used for padding when needed. The transformation is reversible and provides no confidentiality.
Base64 does not protect secrets
Anyone who receives Base64 data can normally decode it without a key. Encoding a password, API key, cookie, token or private data as Base64 does not encrypt it. Security must come from the surrounding protocol and controls — for example TLS in transit and appropriate cryptographic protection or secret storage when required.
Why Base64 usually grows by about one third
Base64 represents every 24 input bits — three bytes — as four symbols carrying six bits each. For large inputs, that changes 3 bytes into 4 encoded characters, producing approximately 33.3% overhead before optional line wrapping or surrounding protocol syntax. Small inputs can have a larger percentage overhead because of padding.
What the = characters mean
Padding completes the final four-character Base64 quantum when the number of input bytes is not a multiple of three. RFC 4648 requires appropriate padding in the general case unless the specification that uses Base64 explicitly states that padding is unnecessary or omitted. This tool therefore lets you control unpadded input/output rather than silently assuming one convention.
Base64URL uses a different alphabet
RFC 4648 defines a URL- and filename-safe Base64 alphabet where + is replaced by - and / is replaced by _. Base64URL is not simply a display preference: a decoder must know which alphabet the surrounding format expects. Some protocols also omit trailing = padding.
Why strict validation matters
PHP base64_decode() has a strict mode that rejects characters outside the Base64 alphabet instead of silently discarding them. This page adds checks for alphabet, length, padding position and canonical round-trip representation. Strict handling is useful when malformed data should be treated as an error rather than quietly repaired.
Why MIME Base64 can contain line breaks
MIME Base64 for email has transport-oriented line rules and permits decoding software to ignore line breaks and other whitespace in that context. RFC 4648, by contrast, says implementations must not add line feeds unless the referring specification directs them to do so. The decoder therefore offers a separate MIME-style whitespace option instead of treating whitespace as universally valid.
Decoded Base64 is bytes, not necessarily text
A Base64 decoder returns the original byte sequence. Those bytes might represent UTF-8 text, an image, compressed data, a certificate, executable data or any other binary format. PHP explicitly documents that decoded output may be binary. When this page detects output that is not safely displayable UTF-8 text, it shows the bytes in hexadecimal instead of pushing arbitrary binary data into the HTML page.
HTTP Basic uses Base64, but Base64 is not its security layer
HTTP Basic authentication constructs user-id:password and Base64-encodes the resulting octets. RFC 7617 explicitly warns that Basic authentication is not secure by itself because Base64 does not protect the credentials. In practice, Basic authentication should only be used with an external secure transport such as HTTPS/TLS and appropriate operational controls.
Base64 encodes bytes; UTF-8 defines how text becomes bytes
Base64 itself does not define whether source text is UTF-8, ASCII, ISO-8859-1 or another character encoding. The same visible characters can produce different byte sequences under different character encodings. Web applications normally work with UTF-8, but interoperability depends on both sides agreeing on the text-to-byte encoding before Base64 is applied.