Base64 encoder and decoder

Encode or decode Base64 and Base64URL for UTF-8 text or any file, with no size limit beyond your RAM.

No file selected. Files are read locally and never uploaded.

What this does

Base64 maps arbitrary bytes onto 64 printable ASCII characters so binary data can pass through systems that only handle text. This tool encodes UTF-8 text or any file you select, and decodes a Base64 string back to text — or, when the bytes aren't valid text, to a downloadable file. It supports both the standard alphabet and the URL-safe variant, and it tolerates missing padding and embedded whitespace on decode.

File encoding happens with the File and FileReader APIs in your browser. The bytes are never uploaded, so encoding a certificate, a private key, or a document to embed in a config file is safe to do here.

When you'd use it

  • Embedding a small image or font in a CSS data: URI or an HTML page.
  • Putting a binary file into a JSON or YAML field that only accepts strings.
  • Decoding the Authorization: Basic header value to see the username and password it carries.
  • Inspecting the payload of a Base64URL token by hand.
  • Preparing a Kubernetes Secret, whose values are Base64-encoded.

Worked example

Encode the text user:pa55 with the standard alphabet:

dXNlcjpwYTU1

That is exactly what sits after Basic in an HTTP Authorization header. Switch Mode to Decode, paste dXNlcjpwYTU1, and you get user:pa55 back — demonstrating that Basic auth offers no confidentiality without HTTPS.

Now tick URL-safe and encode the bytes 0xFB 0xFF (paste them as text won't work; use a 2-byte file). Standard Base64 gives +/8=; URL-safe gives -_8 — same bytes, different characters, no padding.

Limits and gotchas

  • Not a cipher. Base64 provides zero secrecy. Encode-then-encrypt, never encode-instead-of-encrypt.
  • Text mode assumes UTF-8. Pasting text in another encoding and encoding it will produce UTF-8 bytes, which may not match what another system expects.
  • Whitespace on decode is ignored, which is lenient. A stricter decoder elsewhere may reject the same input if it contains newlines.
  • Large files are held entirely in memory as a string during encoding; multi-hundred-megabyte files can exhaust the tab.
  • MIME line wrapping (76-character lines) is not added. If a legacy system needs wrapped output, wrap it after copying.

Frequently asked questions

What is the difference between Base64 and Base64URL?
Standard Base64 uses +, /, and = padding. Those three characters have special meaning in URLs and filenames, so Base64URL replaces + with -, / with _, and usually drops the = padding. The decoded bytes are identical; only the text representation differs. JWTs use Base64URL.
Why did decoding produce garbled characters?
The Base64 decoded fine, but the resulting bytes are not UTF-8 text — they might be an image, a gzip stream, or text in another encoding. This tool detects that and offers a download instead. Garbled output specifically means the bytes were forced through a UTF-8 decoder that couldn’t make sense of them.
Is Base64 encryption? Is it safe to put a password in it?
No. Base64 is a reversible encoding with no key. Anyone can decode it instantly. It exists to carry binary data through text-only channels (email, JSON, URLs), not to protect anything. Never treat a Base64 string as a secret in itself.
The encoded output is bigger than my input — is that expected?
Yes. Base64 represents every 3 bytes as 4 ASCII characters, so output is about 33% larger than input, plus padding and any line breaks. This is the cost of using only printable characters.