Base64 Encode/Decode

What Base64 Actually Does

Base64 rewrites arbitrary binary data using only 64 characters that survive text-only channels: A-Z, a-z, 0-9, +, and /. It works by taking three bytes (24 bits) at a time and re-slicing them into four 6-bit groups, each of which indexes into that alphabet. Three bytes in, four characters out — which is why Base64 output is always about 33% larger than the input.

When the input length is not divisible by three, the final group is padded with one or two = characters. That trailing = or == is usually the fastest way to recognise Base64 in a log line or a config file.

Base64 Is Encoding, Not Encryption

This is the single most consequential misunderstanding about Base64, and it shows up in real breaches. Base64 uses no key and hides nothing — anyone who has the string can recover the original bytes in one step, which is exactly what this page does. An HTTP Basic Auth header is a Base64-encoded username:password, and decoding it is trivial; it is protected by TLS on the wire, not by the encoding. Never treat Base64 as a way to obscure a secret, and never store credentials "encoded" in a config file and consider them protected.

Where You Will Encounter It

• HTTP Basic Auth. Authorization: Basic dXNlcjpwYXNz decodes to user:pass.
• JWTs. Each of the three segments is Base64URL. If you are looking at a token specifically, the JWT Decoder splits and parses all three segments for you and checks the expiry.
• Data URIs. src="data:image/png;base64,iVBORw0..." embeds a whole image inside HTML or CSS, trading a bigger file for one fewer request.
• Email attachments. MIME has encoded binary attachments this way since the 1990s, because SMTP was specified for 7-bit text.
• Kubernetes Secrets. Values in a Secret manifest are Base64 — which is encoding for transport, and routinely mistaken for encryption at rest.
• Certificates and keys. Everything between -----BEGIN CERTIFICATE----- and the matching END line is Base64-encoded DER.
• Malware and phishing analysis. Obfuscated payloads are frequently Base64 blobs; decoding is the first triage step.

Standard Base64 vs. Base64URL

Standard Base64 uses + and /, both of which have meaning inside URLs — + can be read as a space and / is a path separator. The URL-safe variant defined in RFC 4648 swaps them for - and _ and usually drops the = padding. JWTs, OAuth parameters, and most modern web APIs use this variant.

If a decode fails on a string full of - and _, that is why: convert - to + and _ to /, re-add padding until the length is a multiple of four, and decode again. If the string came out of a query parameter it may also be percent-encoded on top — the URL Encoder/Decoder peels that layer off first.

Unicode and the Classic btoa Trap

The browser's built-in btoa() operates on Latin-1 and throws an InvalidCharacterError the moment it meets a character above U+00FF — an emoji, an accented name, any CJK text. Working code converts the string to UTF-8 bytes first and Base64s those bytes. This tool does that on both directions, so non-ASCII text round-trips correctly instead of throwing or producing mojibake.

Troubleshooting a Failed Decode

• Length is not a multiple of 4. Padding was stripped somewhere. Add = until it is.
• Whitespace or newlines. MIME wraps Base64 at 76 columns; strip the line breaks before decoding.
• It decoded, but to binary garbage. The payload was not text — it may be a compressed or image blob, in which case the bytes are correct and simply not printable.
• Double encoding. If the decoded output is itself another Base64 string, decode again. This happens often in nested webhook payloads.

Privacy

Encoding and decoding happen in the page using standard browser APIs. Nothing is transmitted to a server, which is the point when the string you are decoding turns out to be an authorization header or a customer record.