Base64 Encoder / Decoder

About Base64 Encoder / Decoder

Base64 represents arbitrary bytes using 64 printable characters, so binary data survives transports that only tolerate text. It costs about 33% in size and provides exactly no confidentiality.

Why encoded output is 33% larger

Base64 packs three bytes (24 bits) into four characters of six bits each, so every payload grows by a third, rounded up to a four-character boundary with = padding. That overhead is why embedding images as data URIs inflates a page, and why sending large binaries through JSON APIs is wasteful compared with a binary transport. The padding itself is optional in base64url: decoders are expected to infer it from the length, which is why JWT segments have no trailing equals signs.

Standard versus URL-safe

Standard base64 uses + and /, which have meaning in URLs and filenames. Base64url substitutes - and _ and usually drops the = padding - it is what JWTs, JWKs and most modern APIs use. Feeding a base64url string to a standard decoder is the usual cause of "invalid base64" errors.

Common use cases

• Building or reading an HTTP Basic authorization header.
• Decoding a base64 blob from a config file, certificate or log.
• Preparing a small binary payload for a JSON field.

Edge cases and gotchas

• Base64 provides no security whatsoever - treat encoded credentials as plaintext.
• Long base64 strings in a URL will hit path and query length limits.