Base64 Encoding Explained (And When Not to Use It)
Base64 turns up in API responses, JWTs, data URIs, email attachments and configuration files. It is simple once you see what problem it solves — and it is regularly misused as if it were encryption. This guide covers both.
What Base64 actually does
Base64 represents arbitrary binary data using only 64 safe text characters: A–Z, a–z, 0–9, plus "+" and "/", with "=" used as padding.
It exists because many systems — email headers, URLs, JSON, YAML, XML — were designed for text and can mangle raw bytes. Encoding first guarantees the data survives the trip.
- Every three bytes of input become four Base64 characters.
- Output is therefore about 33% larger than the input.
- Padding "=" characters make the length a multiple of four.
- It is fully reversible: encode then decode returns the exact original bytes.
Base64 is not encryption
There is no key and no secret. Anyone who sees a Base64 string can decode it in seconds, including with this tool. Treat encoded credentials as if they were written in plain text.
The classic example is an HTTP Basic Authorization header: the username and password are merely Base64-encoded, which is why it must only ever be sent over HTTPS.
Encoding and decoding step by step
Open the Base64 Encoder & Decoder and choose Encode or Decode. Paste your text into the input box and the result appears instantly below.
To embed an asset, switch to Encode and load a file — you get the Base64 body of its data URI, ready to paste into CSS or JSON.
Copy the output with one click, or press Clear to reset both boxes.
Common mistakes
- Pasting URL-safe Base64 that uses "-" and "_" instead of "+" and "/".
- Dropping the trailing "=" padding when copying from a terminal or log.
- Base64-encoding large images into CSS, which bloats the stylesheet and blocks rendering.
- Assuming a decoded JWT payload is verified — decoding does not check the signature.