Base64 Encoder & Decoder

What is Base64?

Base64 is a way to write arbitrary binary data using only 64 printable characters that survive text-only transport. It exists because a lot of infrastructure was built on the assumption that it would only ever carry text. Old mail servers stripped the eighth bit off every byte. HTTP headers cannot contain raw newlines or null bytes. A JSON string field cannot hold an arbitrary byte sequence at all. Base64 solves that class of problem once: turn the bytes into safe characters, ship them through the text-shaped pipe, turn them back into bytes at the other end.

That is the whole job. It is a transport encoding, not a transformation of meaning — the output carries exactly the same information as the input, in a shape more channels are willing to accept.

How the encoding works

The encoder reads the input three bytes at a time. Three bytes are 24 bits, and 24 divides evenly into four groups of six. Each 6-bit group indexes into a 64-symbol alphabet — A-Z, then a-z, then 0-9, then + and /. So every three input bytes become exactly four output characters.

When the input length is not a multiple of three, the last group is short. The encoder zero-fills the missing bits and appends = characters so the output still arrives in blocks of four: one = when a byte is missing, two when two are. That is why so much Base64 in the wild ends in a single equals sign.

Four characters out for every three bytes in means a 33% size increase, before any line-wrapping overhead. Our team treats that number as the reason not to inline large assets as data URIs by default: a 400 KB photo becomes roughly 533 KB of markup that cannot be cached separately, cannot be lazy-loaded, and has to be parsed with the document. For an icon it is a reasonable trade. For a hero image it usually is not.

Common use cases

• Email attachments. MIME defined Base64 as the standard content transfer encoding, which is why a mail source view shows long blocks of nonsense characters.
• Binary inside JSON. JSON has no byte type, so certificates, thumbnails, and signatures get carried as Base64 strings. If you also move data between config formats, theJSON/YAML converterpairs well with this page.
• Data URIs. A small inline asset written asdata:image/svg+xml;base64,... saves a request.
• HTTP headers. HTTP Basic authentication is a Base64 ofuser:password — encoded, not protected.
• Kubernetes secrets and CI variables. Values are stored Base64-encoded so that arbitrary bytes fit into a YAML string field.

Worth stating bluntly, because the confusion is everywhere: Base64 is neither encryption nor compression. It has no key, provides zero confidentiality, and anyone can reverse it in one line. Base64-encoding a password only hides it from a casual glance. And because it makes data larger rather than smaller, it is the opposite of compression.

Base64 vs base64url

Standard Base64 has three characters that cause trouble in URLs and filenames.+ means a space when a query string is form-decoded,/ looks like a path separator, and= is a key-value separator that also tends to get percent-escaped by one layer and not another.

RFC 4648 section 5 defines the URL-safe variant for exactly this: the same algorithm, but+ becomes - and/ becomes _. Padding is usually stripped, since the length already implies it. This is what JWTs use — each of the three dot-separated segments in a token is base64url, which is why a decoded header reads as{"alg":"HS256","typ":"JWT"}. To inspect claims and verify a signature, ourJWT debuggeris the better tool for that job.

This decoder accepts both alphabets and restores missing padding, so you can paste a raw JWT segment without editing it first.

Tips and gotchas

• The classic btoa() failure. The browser's built-in btoa() accepts one byte per character, so any character above U+00FF throwsInvalidCharacterError. Korean text, emoji, and curly quotes all trip it. The fix is to encode to UTF-8 bytes first and Base64 those bytes — which is what this page does, so round-tripping 안녕하세요 works.
• Whitespace in pasted Base64. Copying from a terminal, a certificate file, or a wrapped email header brings newlines along. Strict decoders reject them; this one strips them.
• Decoded bytes are not always text. If the payload was a PNG or a protobuf, forcing it through a text decoder produces mojibake or an error rather than something useful. A decode failure here often means the data was simply never text.
• Truncation is easy to miss. A string whose length leaves a remainder of one cannot be valid Base64 — it almost always means characters were lost in copying. Move long payloads with text shareinstead of a chat window that soft-wraps.
• Encoding is not sanitising. Decoded content still needs the same validation and escaping as any other untrusted input.

Everything on this page runs locally in your browser. Tokens, keys, and payloads pasted here are never sent to a server.