How Base64 encoding works — and when you actually need it
Base64 is a way of writing any bytes — text, an image, a PDF, a cryptographic key — using
only 64 safe, printable characters: A–Z, a–z, 0–9,
+ and /, with = as padding. It exists because much of
the internet was built for text: email bodies, JSON, HTTP headers, and URLs all assume the
data they carry is printable text, and raw binary bytes get mangled or rejected on the way
through. Base64 respells the bytes so they survive the trip.
The mechanism is simple. The encoder reads your data three bytes at a time — 24 bits — and re-slices those 24 bits into four groups of six bits. Each six-bit group is a number from 0 to 63, and each number picks one character from the fixed 64-character alphabet. So every three bytes in become exactly four characters out, and the output is always about 33% larger than the input. That size cost is the whole price of the trick: Base64 never compresses anything, and if a tool promises a smaller file, it is doing something else as well.
A worked example
Take the text Hello, World! — 13 bytes in UTF-8. In groups of three:
Hel, lo,, Wo, rld, and a final short group
!. The first four groups become four characters each; the last group is one byte
short of three, so it produces two characters and two = padding characters. The
result is SGVsbG8sIFdvcmxkIQ== — 20 characters, and decoding it returns exactly
Hello, World!. Try it above: paste the encoded string, switch to Decode, and
watch it come back. Unicode works the same way, because the text is turned into UTF-8 bytes
first: Hello, 世界 👋 is 18 bytes and encodes to
SGVsbG8sIOS4lueVjCDwn5GL, with no padding because 18 is a multiple of 3.
Where Base64 shows up in real work
Data URIs. A small image can be embedded directly in HTML or CSS as
data:image/png;base64,iVBORw0… — the part after ;base64, is the file's
bytes in Base64. It saves an HTTP request but costs ~33% more bytes, so it only pays off for
tiny assets like icons. This tool's File → Base64 panel produces exactly that payload.
Basic authentication. An HTTP Authorization: Basic header is the
Base64 of username:password. That is why you will see strings like
dXNlcjpwYXNzd29yZA== in API docs — and why it is not security: anyone who sees
the header decodes it instantly. It only ever travels over HTTPS.
Email attachments (MIME). Email is a text protocol, so attachments are
Base64-encoded and wrapped at 76 characters per line. If you have ever opened a raw
.eml file and seen a wall of Base64, that is a file in transit. This decoder
ignores line breaks and whitespace, so you can paste a MIME block as-is.
APIs and tokens. JSON cannot carry raw bytes, so APIs pass binary data — images, signatures, encrypted blobs — as Base64 strings. JWTs (JSON Web Tokens) are three Base64url segments joined by dots: header, payload, signature.
Standard Base64 vs URL-safe Base64 (base64url)
| Variant | Alphabet | Padding | Where you see it |
|---|---|---|---|
| Standard (RFC 4648 §4) | A–Z a–z 0–9 + / | Required (=) | btoa(), most language APIs, MIME email |
| URL-safe (RFC 4648 §5) | A–Z a–z 0–9 - _ | Usually omitted | JWT, OAuth PKCE, URL parameters, file names |
The only difference is the last two characters: standard Base64's + and
/ have special meanings in URLs — + becomes a space in a query
string, and / looks like a path separator — so base64url swaps them for
- and _ and usually drops the padding. Use the URL-safe toggle above
whenever the output goes into a URL, a cookie, or a JWT; decoding here accepts both alphabets,
with or without padding, so you never have to convert between them by hand.
Padding rules, in one paragraph
Output length is always a multiple of 4. If the input is a multiple of 3 bytes, there is no
padding. One leftover byte gives two = signs; two leftover bytes give one. The
padding carries no data — it only marks where the real bytes end — which is why decoders that
know the input length can drop it. This tool repairs missing padding automatically when
decoding, and it rejects a length that is 1 more than a multiple of 4, because no valid
Base64 string can have that length.
Mistakes this tool is built to catch
Treating Base64 as encryption
Base64 hides nothing. A "secret" in Base64 is plain text with extra steps — anyone can decode it. If you need confidentiality, encrypt first, then Base64-encode the ciphertext if a text channel requires it.
Pasting standard Base64 into a URL
+ and / break in URLs and file names. If your encoded string
is going into a link, a cookie, or a JWT, switch on the URL-safe toggle before copying.
Forgetting the padding
Strict decoders in Python, Java, and Go reject Base64 with missing =.
Keep padding on unless the receiving system (like JWT) explicitly wants it off — this
decoder repairs it, but theirs might not.
Using btoa() on emoji or accented text
JavaScript's btoa() only handles one byte per character and throws on
anything outside Latin-1. Text must be UTF-8-encoded first — which this tool does — or
the emoji in your string will break the encode.
Decoding binary as text
If the Base64 came from an image or a PDF, decoding it to text gives replacement characters, not the file. Use the Base64 → file panel instead: it rebuilds the original bytes and downloads them, and even tells you what file type they look like.
Expecting a smaller file
Base64 always adds ~33%. Encoding a 3 MB photo gives a ~4 MB string. That is the format working as designed — if size matters, compress the file first, then encode it.