Skip to content

Base64 Encoder/Decoder

Encode and decode text or files to and from Base64, with URL-safe output, file uploads, and size statistics.

Base64 encoder / decoder

Empty
Paste text or drop a file to encode. Flip to Decode to paste Base64 and recover the original.
Input Paste · drag-drop · upload
0 chars
Output Encoded
0 chars


                

        
      

Examples

How It Works

Base64 is a binary-to-text encoding: it turns any sequence of bytes into a string of 64 printable ASCII characters (A–Z, a–z, 0–9, +, /) plus = for padding. Every 3 input bytes become 4 output characters, so encoded output is always about 4/3 × larger (≈33% overhead). It exists because many transports — email bodies, HTTP headers, JSON strings, URLs, XML attributes — only safely carry text, not arbitrary bytes.

Decoding is the reverse. Four Base64 characters combine their 6-bit values into three bytes. If the input length isn't a multiple of 4, padding = signals how many bytes are in the last group (0, 1, or 2). Modern decoders accept input with or without padding, but strict ones will reject it.

The URL-safe alphabet (RFC 4648 §5) swaps + and / for - and _ so the string can live in a URL path or query without percent-encoding. JWTs, OAuth tokens, and data: URLs for images in CSS/HTML all lean on Base64. MIME uses the classic alphabet but wraps every 76 characters to fit email line-length limits.

This tool encodes the full Unicode range by first serializing text to UTF-8 bytes, then applying Base64. When you upload or drop a file, it reads the raw bytes directly — images, PDFs, zip files round-trip without corruption. Decoding detects common binary signatures (PNG, JPG, PDF, GIF) and shows a preview when the result is viewable.

Tips & Best Practices

Base64 is not encryption. It is trivially reversible — anyone can decode it. Use it for transport, never for secrecy.
Encoded output is about 33% larger than the input (4 chars per 3 bytes). Account for this when packing Base64 into cookies, JWT payloads, or request bodies with size limits.
Use the URL-safe alphabet for anything that ends up in a URL, filename, or JSON Web Token. It replaces + / / with - / _.
Strip = padding only when the decoder on the other side accepts it (JWT does, most MIME tooling does not).
For binary data, always encode from raw bytes, not from a text representation. This tool does it automatically when you drop a file.
If decode fails with "invalid character", check for whitespace, URL-encoding (%3D instead of =), or a mismatched alphabet (URL-safe vs standard).

Frequently Asked Questions

What is Base64 used for?

Embedding binary data inside text-only transports: email attachments (MIME), inline images in HTML/CSS via data: URLs, JSON Web Tokens, OAuth state parameters, API keys, SSH public keys, TLS certificates (PEM), and serialized protobuf in web forms. It is the lowest-common-denominator way to push bytes through a channel that expects text.

No. Base64 is a public, reversible encoding — anyone with the output can recover the input. It provides zero confidentiality. If you need to protect data, encrypt it first and then Base64-encode the ciphertext for transport.

Base64 processes input in 3-byte groups and emits 4-char groups. When the final group has only 1 or 2 bytes, the output is padded with 1 or 2 = characters so the total length stays a multiple of 4. Some decoders require this padding; many (JWT, for example) omit it.

Standard Base64 (RFC 4648 §4) uses A-Z a-z 0-9 + /. URL-safe Base64 (§5) swaps the last two for - and _, because + and / have reserved meanings in URLs and filenames. The two alphabets are incompatible — you must decode with the same one that was used to encode.

Usually a charset mismatch. This tool assumes UTF-8 when decoding to text; if the bytes were encoded from Latin-1 (Windows-1252), Shift_JIS, or another encoding, the bytes are valid but interpreting them as UTF-8 produces mojibake. Switch the Decode as control to "Latin-1" or "Hex bytes" to see the raw bytes.

Everything runs in your browser — no upload happens. Practical limits are your device memory and how much text the <textarea> can render. Hundreds of KB are fine; multi-MB files work but the output pane will get sluggish. For very large files, use a command-line tool (base64 on macOS/Linux, certutil on Windows).

No. All encoding, decoding, file reading, SHA-256 hashing, and MIME detection happen locally in your browser using the native btoa / atob and SubtleCrypto APIs. The shareable link option encodes content into the URL hash, which is also never sent to the server.