Base64 Encode / Decode

When to use this

You're debugging an API response and one of the fields is a blob of characters ending in "==" — that's Base64. You need to decode it to see the actual data inside. Or you're looking at a JWT token and want to read the payload: split the token on the dots, grab the middle segment, and paste it here to reveal the JSON claims.

Encoding is just as common. You need to embed a small image directly in CSS or HTML as a data URI. You're setting up Basic Auth and need to encode "username:password" into the Authorization header value. You're stuffing binary data into a JSON field or an environment variable that only accepts text. Base64 is the standard way to make binary safe for text-only channels.

In plain terms, Base64 takes every 3 bytes of input and represents them as 4 ASCII characters from a 64-character alphabet (A-Z, a-z, 0-9, +, /). The "==" padding at the end fills out the last group when the input isn't evenly divisible by 3. That's the entire trick — it's encoding, not encryption. Anyone can decode it.

Good to know

Base64 is not encryption. It's a common misconception. Base64 is a reversible encoding — there's no key, no secret, no security. If you see credentials stored as Base64 "for security," that's a red flag. Anyone can decode it instantly. It exists purely to make binary data safe for text transport, not to hide anything.

JavaScript's btoa() breaks on Unicode. The built-in btoa() function only handles Latin-1 characters. Feed it an emoji, an accented character, or any multibyte UTF-8 and you'll get "Failed to execute 'btoa'." The correct approach — and what this tool uses — is to encode to UTF-8 bytes first, then Base64-encode those bytes. The TextEncoder API makes this clean.

Base64 increases size by ~33%. Every 3 bytes become 4 characters. A 1MB image becomes ~1.33MB as a data URI. For small assets (icons, tiny SVGs) the overhead is worth avoiding an extra HTTP request. For anything above a few KB, serve the file normally.

Power user tip: Base64url is a thing. Standard Base64 uses + and /, which are special characters in URLs. Base64url (RFC 4648 Section 5) swaps those for - and _ and drops the padding. JWTs use Base64url, not standard Base64 — so if you're manually decoding a JWT segment and the output looks garbled, that's probably why.

Quick Reference

Input	Base64 Output	Notes
Hello	SGVsbG8=	Single = pad (5 bytes, 1 leftover)
Hi	SGk=	One pad character
ABC	QUJD	No padding needed (3 bytes divides evenly)
user:pass	dXNlcjpwYXNz	HTTP Basic Auth format
{"sub":"1234"}	eyJzdWIiOiIxMjM0In0=	JWT-style JSON payload