An Encoding, Not a Cipher
Base64 exists because a lot of infrastructure was built assuming text. Email headers, JSON strings, URLs and data attributes all handle printable ASCII reliably and arbitrary bytes badly, so binary gets re-expressed in 64 safe characters to survive the trip.
This tool encodes and decodes text, with URL-safe and unpadded variants for the contexts that need them.
How to Encode or Decode
The conversion runs as you type, in whichever direction the mode is set to.
- Paste your text into the input.
- Choose the direction, encoding text to base64, or decoding base64 back to text.
- Enable URL-safe if the result goes in a URL or filename. It replaces `+` with `-` and `/` with `_`.
- Disable padding if the receiving system expects no trailing `=` characters, as JWT segments do.
- Read the byte counts. Base64 output is about a third larger than the input, and the counters make that visible.
- Copy the result, or use the swap control to feed the output back in and check the round trip.
How the Encoding Works
Base64 takes three bytes, 24 bits, and re-splits them into four 6-bit groups, each mapped to one of 64 characters. Three bytes in, four characters out, which is where the roughly 33 per cent size increase comes from. When the input length is not a multiple of three, the final group is padded with `=` so the output length stays a multiple of four.
This tool encodes text as UTF-8 before the base64 step, which matters for anything outside ASCII. A single emoji is four bytes in UTF-8 and becomes eight base64 characters; Korean, Chinese and Japanese characters are typically three bytes each. The byte counter shows the real input size rather than the character count, since those diverge sharply outside ASCII.
Variants and Where They Are Used
The differences are small and the contexts are unforgiving about them.
| Variant | Characters 62 and 63 | Padding | Typical use |
|---|---|---|---|
| Standard | + and / | Yes, with = | Email, data URIs, general encoding |
| URL-safe | - and _ | Often omitted | URLs, filenames, JWT segments |
| Unpadded | Either set | No | JWT, some APIs, compact tokens |
A standard-encoded string put into a URL will usually survive, right up until a `+` is interpreted as a space or a `/` splits the path. That failure is intermittent, since it depends on whether the particular value happens to contain those characters.
What Base64 Is Not For
It is not encryption and offers no confidentiality whatsoever. Decoding requires no key and takes no effort, so a base64-encoded password is a plaintext password with an extra step. It appears in HTTP Basic authentication for exactly this reason, as a transport encoding, not a protection, which is why Basic auth is only acceptable over TLS.
The format also carries no integrity guarantee. Nothing in a base64 string indicates whether it arrived intact, so a value truncated in transit decodes to whatever the surviving bytes happen to mean, or fails outright. Where that matters, a checksum alongside the encoded value is what catches it.
It is also not a compression format. Base64 makes data about a third larger, so encoding a file to embed it in HTML or JSON trades bandwidth for convenience. That trade is usually worth it for small icons and worth avoiding for anything sizeable. Everything here runs in your browser and nothing you paste is transmitted or stored.