Is Base64 encryption? No — and the gap between those two words is where a lot of accidental data exposure lives. Base64 output looks scrambled, which is enough for it to get used as if it were a lock. It is not a lock. There is no key involved, nothing is secret, and anyone who recognises the format can read it back in one step.
Here is what Base64 actually does, what it is genuinely good for, and the specific mistakes that come from confusing encoding with encryption.
Is Base64 encryption, or is it encoding?
It is encoding, and the difference is not pedantry. An encoding is a public, reversible change of representation — the rules are published, everyone has them, and there is no secret input. Encryption takes a key, and without that key the plaintext stays out of reach.
Base64 is specified in RFC 4648, published by the IETF in October 2006. Its own Security Considerations section says the quiet part out loud: "Base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality."
Visually hides is the whole of it. Decoding takes one line of code in any language with a standard library, or a paste into a Base64 decoder. If you need something an attacker cannot read, you need encryption with a key you control — or you need to not send the thing at all.
What Base64 is genuinely for
The real job is moving binary data through channels that only reliably carry text. Plenty of long-standing infrastructure was built for characters, not arbitrary bytes, and raw binary passing through it gets mangled, truncated at a null byte, or rewritten by a gateway. Base64 re-expresses those bytes using a small, safe alphabet so they survive the trip.
- Email attachments. RFC 2045, the MIME specification from November 1996, defines base64 as a Content-Transfer-Encoding "designed to represent arbitrary sequences of octets in a form that need not be humanly readable". That is how a PDF crosses a mail path that only guarantees 7-bit text.
- Data URIs. RFC 2397, from August 1998, defines the
data:URL scheme with the formdata:[<mediatype>][;base64],<data>, which is how a small icon gets embedded directly in HTML or CSS. - JSON payloads. JSON has no binary type, so a blob of bytes travels as a Base64 string in a text field.
- JWTs. Every segment of a token is Base64url — more on that below.
Notice what is absent from that list: secrecy. Not one of these uses is about hiding anything. They are all about safe transport.
Why Base64 makes data about 33 percent bigger
Base64 works on 24 bits at a time — three bytes — and re-expresses them as four characters carrying six bits each. Six bits gives 64 possible values, which is where the name comes from: A-Z, a-z, 0-9 and two more (+ and / in the standard alphabet).
Four characters out for every three bytes in is a ratio of 4:3, so RFC 2045 states that "the encoded data are consistently only about 33 percent larger than the unencoded data". That overhead is the price of text safety, and it is usually fine — but it has a practical edge. A 200 KB image inlined as a data URI is roughly 267 KB of characters sitting inside your HTML or CSS, and it can no longer be cached separately from the document that contains it. Worth it for a tiny icon; rarely worth it for a photograph.
Why Base64 often ends with = or ==
Because the input is not always a neat multiple of three bytes, and the output is padded so it always lands on a multiple of four characters. RFC 2045 spells out the three cases:
| Bytes left over | Output |
|---|---|
| None (input is a multiple of 3) | Four characters, no padding |
| Two bytes | Three characters plus one = |
| One byte | Two characters plus two == |
So the trailing equals signs are arithmetic, not meaning. They tell you the length of the original data modulo three and nothing else — not what it contains, not that it is encrypted, not that it is a token. RFC 4648 requires the padding by default: "Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise." Some specifications do explicitly state otherwise, which is why JWTs have no equals signs in them.
The URL-safe variant, and why it exists
The last two characters of the standard alphabet cause trouble outside a mail body. / is a path separator in a URL, and + has to be percent-encoded in a query string to avoid being read as a space. Both are awkward in filenames.
So RFC 4648 Section 5 defines a second alphabet, the URL and filename safe one. It is "technically identical to the previous one, except for the 62:nd and 63:rd alphabet character": + becomes - and / becomes _. Everything else is unchanged, which means a decoder only has to know which of the two alphabets produced the string. If you are also wrestling with percent-encoding in URLs, that is a URL Encoding Explained: Why Spaces Become %20.
HTTP Basic auth is Base64, not encryption
This is the mistake with the sharpest edge. RFC 7617, from September 2015, defines the Basic HTTP authentication scheme: the client joins the user-id, a colon and the password into one string, Base64-encodes it, and sends it in the Authorization header. No key, no secret, no protection. Anyone who captures that header recovers the password by decoding it.
The RFC is blunt about this. Basic authentication is "not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network used as the carrier", and it "SHOULD NOT be used (without enhancements such as HTTPS) to protect sensitive or valuable information". Basic auth over TLS is fine — but every bit of the confidentiality comes from TLS, and none from Base64.
The same logic kills a habit you will find in a lot of config files: Base64-ing an API key and treating it as obscured. It is a speed bump for someone skimming a file, and nothing whatsoever for anyone who cares. Encoding a secret does not make it less of a secret in plaintext. The related error on the hashing side is assuming a hash can be reversed, which is covered in MD5 vs. SHA-256.
A JWT payload is Base64url, and anyone can read it
A JSON Web Token, specified in RFC 7519 from May 2015, is three Base64url segments joined by periods: header, payload, signature. RFC 7515 defines Base64url Encoding as "Base64 encoding using the URL- and filename-safe character set defined in Section 5 of RFC 4648, with all trailing ‘=’ characters omitted" — which explains both the - and _ characters you see in tokens and the absence of padding.
The signature is what people misread. It proves the claims were not altered and that they came from someone holding the signing key. It does not hide them. Paste any token into a JWT decoder and the payload reads out as plain JSON, no key required — which is exactly why RFC 7519 warns that "a JWT may contain privacy-sensitive information. When this is the case, measures MUST be taken to prevent disclosure of this information to unintended parties." The fix is an encrypted token, not a signed one.
The working rule: never put anything in a JWT payload you would not be comfortable printing in a URL. No passwords, no API keys, no internal identifiers you would rather not publish. If a token has to carry something sensitive, that is a job for JWE or for keeping the data server-side behind an opaque session identifier.
Encode and decode text and files — everything runs in your browser.
Open Base64 Tool →Frequently asked questions
No. Base64 provides no security at all. RFC 4648 states that base encoding visually hides recognisable information such as passwords but does not provide any computational confidentiality. There is no key, and decoding is a single step that anyone can perform.
Yes, completely and by anyone. Base64 is a public encoding scheme with published rules, so decoding requires no secret. That is the defining difference between encoding and encryption: reversing encryption requires a key, reversing an encoding requires only the specification.
Padding. Base64 converts three bytes into four characters, so when the input length is not a multiple of three the output is padded to keep it a multiple of four characters. Two leftover bytes produce one equals sign, one leftover byte produces two. It says nothing about the content.
Carrying binary data through channels that only reliably handle text: MIME email attachments, data URIs that embed images in HTML or CSS, binary fields inside JSON, and the segments of a JSON Web Token. None of these uses involve secrecy.