Toolbit

Base64 Encoder & Decoder

Encode text to Base64 and decode Base64 back to text, with UTF-8 support, the base64url variant, and optional padding.

What Base64 is

Base64 is a way to represent binary data using only safe text characters: letters, digits, and two symbols. It exists because many channels were designed to carry text, not arbitrary bytes — email, HTTP headers, JSON and XML documents, URLs. An image file, a cryptographic key, or any byte sequence containing non-printable values would get mangled passing through those channels; encoded as Base64, it travels as plain text and comes out the other end exactly the same.

It's just as important to be clear about what it isn't: Base64 is neither encryption nor compression. Anyone can decode it without a key, and the result is always larger than the original. Its only job is making data survive transport.

How it works, in one line

The alphabet has 64 symbols, and 64 = 2⁶, so each Base64 character represents exactly 6 bits. The encoder takes input bytes three at a time (24 bits), splits them into four 6-bit chunks, and replaces each chunk with its symbol. Three input bytes always produce four output characters. The bit-by-bit walkthrough, with worked examples, is in Base64 Explained: How It Works, Padding, and Variants.

ValuesSymbolsNotes
0 – 25A – Z
26 – 51a – z
52 – 610 – 9
62+- in base64url
63/_ in base64url
padding=fills out the final 4-character block

How to use the tool

  • Encode: the text is first converted to bytes using UTF-8, then to Base64. So ñ produces w7E=, and an emoji is encoded from its four bytes — exactly what any modern programming language would do.
  • Decode: accepts both the standard and base64url alphabets, with or without trailing =, and ignores spaces and line breaks (email and PEM files wrap Base64 into 64- or 76-character lines). If a character isn't part of the alphabet, the tool tells you which one and where.
  • Binary content: if the decoded bytes aren't valid UTF-8 text (say, the Base64 of an image or a key), the result is shown as hexadecimal bytes instead of garbled characters.
  • Use result as input flips the operation in one click — handy for confirming that a round trip gives back the same thing.

How much bigger it gets

Since 3 bytes become 4 characters, Base64 adds roughly 33% to the original size, plus padding on the final block. The exact formula for padded output is 4 × ⌈n / 3⌉:

Input bytesBase64 characters
14
24
34
1016
100136
1,024 (1 KiB)1,368
1,048,576 (1 MiB)1,398,104

That 33% matters when you inline images in CSS or HTML as data URIs: a 300 KB image turns into about 400 KB of text inside the document, and it can no longer be cached on its own. For small icons, saving an HTTP request is worth it; for large images, it almost never is.

Standard Base64 vs. base64url

RFC 4648 defines two alphabets that differ in just two symbols. The standard one uses + and /, which mean something in URLs (+ can be read as a space in a query string, and / separates path segments) and in file names. The base64url variant swaps them for - and _, and in practice usually drops the trailing =, since that's a reserved URL character too. It's the variant used by JSON Web Tokens (JWTs), many link-embedded identifiers, and keys in JWK format.

Common uses

  • Email attachments (MIME): the original format that made Base64 popular, with lines wrapped every 76 characters.
  • Data URIs: data:image/png;base64,... lets you embed small files directly in HTML or CSS.
  • HTTP Basic authentication: the header Authorization: Basic dXN1YXJpbzpjbGF2ZQ== is nothing more than usuario:clave in Base64. Without HTTPS, anyone who sees the request can read the password.
  • JWTs: a token's header and payload are JSON encoded as base64url, readable by anyone. What protects the token is its signature, not the encoding.
  • PEM keys and certificates: the block between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- is the certificate's binary structure encoded in Base64.
  • Binary fields in JSON: JSON has no bytes type, so APIs typically send files or signatures as Base64 strings.

From the shell and in code

On Linux and macOS, base64 encodes and base64 -d decodes (-D on older macOS). A very common slip is using echo without -n: echo 'Hola' | base64 produces SG9sYQo= because it also encodes the trailing newline, while printf 'Hola' | base64 gives the expected SG9sYQ==. In browser JavaScript, btoa() only accepts single-byte characters: btoa("€") throws an error, and btoa("ñ") returns 8Q== (Latin-1) instead of UTF-8's w7E=. That's why you need to convert the text with TextEncoder first — which is exactly what this tool does.

Privacy

Encoding and decoding happen entirely in your browser. What you type is never sent to a server or stored in the URL, so you can use the tool with test tokens or credentials without them leaving your machine.

Frequently asked questions

Does Base64 protect information?

No. Base64 is an encoding, not encryption: it uses no key, and anyone can reverse it instantly. It's for carrying bytes over text-only channels. Protecting data takes actual encryption (AES, for example) or, for passwords, a slow hash like bcrypt or Argon2.

Why do some Base64 strings end in = or ==?

Because Base64 works in 3-byte blocks. If 1 byte is left over at the end, the final 4-character block is filled out with ==; if 2 bytes are left over, with a single =. When the byte count is a multiple of 3, there's no padding. The base64url variant usually drops the padding altogether.

Why does the same text give a different Base64 in another tool?

There are three usual culprits: an extra trailing newline (echo without -n), a different character encoding (Latin-1 instead of UTF-8, which changes the output for letters like ñ or é), or the base64url variant, which swaps + and / for - and _. This tool always uses UTF-8 and never adds line breaks.