Base64 Encode

Base64 is a binary-to-text encoding that represents arbitrary bytes using 64 ASCII characters: A-Z, a-z, 0-9, +, and /, with = for padding. The variant called base64url swaps + and / for - and _ so the output is safe inside URLs and HTTP headers without further escaping. The tool above runs entirely in your browser; no input ever leaves your machine.

How the encoding works

Base64 takes input bytes 3 at a time and emits 4 ASCII characters. Each character represents 6 bits of the input (since 2⁶ = 64). The arithmetic:

• 3 bytes = 24 bits, which split cleanly into 4 × 6-bit groups.
• Each 6-bit group indexes into the 64-character alphabet.
• If the input length isn’t a multiple of 3, the encoder pads the final group with zero bits and appends = characters so the output length is always a multiple of 4.

A worked example. Encoding the three-byte string Cat:

Bytes:  C       a       t
Hex:    0x43    0x61    0x74
Binary: 01000011 01100001 01110100

6-bit groups: 010000 110110 000101 110100
Decimal:      16     54     5      52
Char (table): Q      2      F      0

Output: "Q2F0"

Cleanly, no padding. Encoding Ca (two bytes) instead:

Binary:       01000011 01100001
Padded:       01000011 01100001 00000000
6-bit groups: 010000 110110 000100 000000  (last group is padding)
Encoded:      Q      2      E      = (last 6-bit group → "=")

Output: "Q2E="

The single = indicates one byte of input was padded. Two = indicates two bytes of input were padded. Output length is always a multiple of 4.

Base64-encoded output is exactly 4/3 the size of the input — a 33% size increase. That’s the cost of representing arbitrary bytes in printable ASCII.

Where you’ll see base64

• Authorization: Basic headers in HTTP. The username:password string is base64-encoded for header transit. (Base64, not hashed — Basic auth is plaintext credentials over the wire; only TLS provides confidentiality.)
• Embedded images in HTML/CSS. The data:image/png;base64,... URL scheme inlines binary image data into a stylesheet or HTML document. Cheap for tiny icons; expensive for anything large.
• JWT segments. Each part of a JWT (header, payload, signature) is base64url-encoded. See the JWT decoder for what each segment carries.
• Email attachments (MIME). SMTP historically transported only 7-bit ASCII; binary attachments are base64-encoded for transit.
• API payloads carrying binary blobs. When a JSON API needs to ship binary data (file contents, public keys, raw signatures), base64 is the standard envelope.

Base64 vs base64url

The two variants differ in three characters:

Use base64url for URLs, query parameters, and HTTP headers — the + and / of standard base64 have meaning in URLs and need percent-encoding (+ becomes %2B, / becomes %2F), which is awkward. base64url avoids the issue at the cost of being slightly less universal.

Use standard base64 for everything else — MIME, email, generic data envelopes, the Authorization: Basic header. Standard base64 is what most libraries default to when you call b64encode().

The encodings are not interoperable: a base64url-encoded string can’t be decoded by a strict base64 decoder if it contains - or _. If you’re consuming an API and getting decoding errors, the variant is the first thing to check.

What base64 isn’t

• It’s not encryption. Decoding base64 doesn’t require a key. Anyone who sees the encoded string can recover the bytes. Treating base64 as obscurity is one of the most common security misunderstandings.
• It’s not compression. Base64 inflates data by 33%. If you need both compression and printable encoding, compress first (gzip, brotli) and then base64 the compressed output.
• It’s not a hash. Hashes are one-way and fixed-length; base64 is reversible and proportional to input size.
• It’s not URL-safe by default. Standard base64 contains + and /. For URL use, switch to base64url.

Common pitfalls

• Whitespace in the encoded string. Some encoders (especially historic MIME implementations) wrap base64 output at 76-character lines. Decoders should tolerate whitespace, but some strict decoders fail. If you’re getting “invalid base64” errors, strip whitespace first.
• Missing padding. Base64url often omits the trailing = padding because the length is recoverable from context. Some decoders require padding; if you see a “wrong length” error, append = characters until the length is a multiple of 4.
• UTF-8 vs raw bytes. Encoding “the string” vs “the bytes that represent the string in UTF-8” is sometimes ambiguous in API docs. Most modern APIs assume UTF-8; older ones (or non-text data) require explicit byte-level encoding.
• Confusing base64 and hex for small values. A 16-byte value is 32 hex chars or roughly 22-24 base64 chars. Hex is human-readable and case-tolerant; base64 is denser but more sensitive to character corruption.

Use the encoder above to convert text (encoded as UTF-8 first); for a whole file, use file to Base64. For the inverse direction, see the base64 decoder.