Free Base64 Encoder & Decoder

Encode plain text to Base64 or decode Base64 back to text. Handles Unicode characters correctly. Runs entirely in your browser — no data sent to any server.

Enter your details
Result
Enter your details on the left, then press Calculate.

Runs entirely in your browser. No text is sent to any server.

What is this calculator for?

You need to embed an image inline in CSS or a JSON document. Or you're debugging an API authentication header (which is often Base64-encoded). Or you're working with email attachments which are Base64-encoded for transport. The Base64 encoder/decoder converts binary data to ASCII text and back — the fundamental tool for embedding binary content in text-only contexts.

Why Base64 exists. Many systems handle ASCII text reliably but treat binary data badly (email, URLs, JSON, HTTP headers, XML). Base64 converts any binary content to a stream of ASCII characters using 64 specific symbols (A-Z, a-z, 0-9, +, /, with = as padding). The resulting text is safe to send through text-only systems, then decoded back to the original binary on the receiving end. Used by: HTTP Basic Authentication, JSON Web Tokens, email attachments (MIME), data URIs in HTML/CSS, embedded images in PDFs.

This tool encodes plain text to Base64 and decodes Base64 back to plain text. For file encoding/decoding: use programming tools (Node.js, Python — the bytes-to-Base64 functions handle files larger than this tool can paste).

How to use this calculator

For encoding: paste text into the input. The tool outputs the Base64-encoded equivalent. "Hello, World!" becomes "SGVsbG8sIFdvcmxkIQ==". The "==" padding at the end is part of Base64 spec.

For decoding: paste Base64 text into the input. The tool outputs the decoded original. Invalid Base64 (wrong characters, wrong length) produces an error.

For URL-safe Base64: standard Base64 includes "+" and "/" which have special meanings in URLs. URL-safe Base64 substitutes "-" and "_" instead. Used in JWT tokens, URL parameters. The tool can encode/decode in both standard and URL-safe variants.

Understanding your results

The encoder outputs Base64 text from plain text input. The decoder outputs original text from Base64 input.

How Base64 works mathematically. Each 3 bytes of binary input become 4 characters of Base64 output. 3 bytes = 24 bits; each Base64 character represents 6 bits; 24 bits / 6 = 4 characters. So Base64 makes the data ~33% larger (4 characters represent what 3 bytes would). The 64 symbols cover all 6-bit combinations (2^6 = 64). Standard alphabet: A-Z (26), a-z (26), 0-9 (10), plus 2 special (+, /) = 64. Padding ("=") appears when input bytes aren't a multiple of 3.

Common Base64 uses you encounter. HTTP Basic Authentication: Authorization: Basic dXNlcjpwYXNzd29yZA== — "dXNlcjpwYXNzd29yZA==" is Base64 for "user:password". Note: HTTP Basic is essentially plaintext over the wire if not using HTTPS — Base64 encoding is not encryption. JWT (JSON Web Token): the dot-separated parts (header.payload.signature) are all Base64-encoded. Data URIs: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA... — inline images embedded in HTML/CSS. Email MIME attachments: binary files Base64-encoded for transport through email systems.

Base64 is NOT encryption. Encoding/decoding Base64 is fully reversible without any key. It's not secure for hiding secrets. If you've Base64-encoded a password thinking it's "encrypted," it's not — anyone with the Base64-encoded string can decode it back to plaintext in 2 seconds. For actual security: use real encryption (AES) plus secure key management.

The 33% size bloat. Base64 makes data 33% larger than the binary original. For 1 MB binary file: ~1.33 MB Base64-encoded. This is why data URIs aren't used for large images (the inflation eats bandwidth); they're used for small icons (under 5-10 KB). For HTTP: typically gzip compression reduces the Base64 bloat by ~25-30%, but the round-trip is still less efficient than transmitting binary directly.

A worked example

A developer is debugging an API authentication problem. The API requires HTTP Basic Authentication; she's getting 401 Unauthorized responses.

The request she's sending: Authorization: Basic dXNlckBleGFtcGxlLmNvbTpwYXNzd29yZA==

She decodes the Base64: "user@example.com:password" — that's the username + password she's using. The format is correct (username:password).

Issue identified: she's sending the wrong password. The actual API requires "RealPassword123" not "password". She re-encodes: "user@example.com:RealPassword123" → "dXNlckBleGFtcGxlLmNvbTpSZWFsUGFzc3dvcmQxMjM=". New request succeeds.

The Base64 decoder revealed the wire-protocol content, helping diagnose the actual credentials being sent (vs what she thought she was sending). Without the decoder: she'd have to manually decode by hand or look up the encoding logic — much slower for debugging.

Variation: a designer wants to embed a small icon (5 KB PNG) inline in CSS rather than as a separate file (to eliminate one HTTP request). She uses a Base64 encoder to convert the PNG to a data URI: background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...); — the entire image embedded as a string. Trade-off: CSS file is larger; one less HTTP request. For small icons, the trade-off favors data URIs; for large images, separate files win.

Related resources

For other encoding/decoding tools, see URL Encoder and Hash Generator. For JSON-specific handling, the JSON Formatter. For text manipulation, the Case Converter. The RFC 4648 is the authoritative IETF specification for Base16, Base32, and Base64 encodings.

Related calculators

url encoderhash generator

Frequently asked questions

What is Base64?

Base64 is an encoding scheme that converts binary data into a text string using 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). It is used when binary data needs to travel through systems that only handle text, such as email (MIME), JSON payloads, or HTML data attributes.

Why use Base64?

The most common uses: embedding images in HTML/CSS as data URLs (src='data:image/png;base64,...'), encoding API credentials in HTTP Authorization headers (Basic auth), storing binary blobs in JSON, and transmitting binary through SMTP. Base64 is not encryption — anyone can decode it.

Is Base64 a form of encryption?

No. Base64 is encoding, not encryption. Encoding is a reversible transformation that any tool can reverse without a key. Encryption requires a secret key and is computationally infeasible to reverse without it. Never rely on Base64 to protect sensitive data — use AES or RSA encryption instead.

Is Base64 encryption?

No. Base64 is encoding, not encryption. Encoding transforms data into a different representation (binary to ASCII text); the transformation is fully reversible without any key. Anyone with the Base64-encoded text can decode it back to original. Encryption transforms data using a key; without the key, decoding is computationally infeasible. Common mistake: storing 'encoded' passwords in databases as Base64 thinking it's safe. It's not; anyone with database access can decode them in seconds. For real password storage: use bcrypt, scrypt, or Argon2 (hashing algorithms designed for password storage); never use Base64 or any encoding alone.

Why does Base64 add 33% to data size?

Math. Base64 represents binary data using 64 ASCII characters (A-Z, a-z, 0-9, +, /). Each Base64 character represents 6 bits. To encode 3 bytes (24 bits) of binary data, you need 4 Base64 characters (4 × 6 = 24 bits). So 3 bytes of binary becomes 4 characters of Base64 — exactly 33% more characters. Plus padding ('=' characters) when input isn't a multiple of 3 bytes. For most uses, the 33% overhead is acceptable. For large files, transmitting binary directly is more efficient when possible.

What characters are in Base64?

Standard Base64 alphabet: A-Z (26), a-z (26), 0-9 (10), + (1), / (1) = 64 total. Plus '=' as padding character (not part of the 64). URL-safe Base64 variant: substitutes - for + and _ for / to avoid URL-encoding issues. So URL-safe Base64 alphabet: A-Z, a-z, 0-9, -, _ with = padding. Some implementations omit padding entirely in URL-safe variants. JWT tokens use URL-safe Base64; standard email and HTTP use the with-+/ variant.

When should I use a data URI vs an external file?

Data URIs for small files (under 5-10 KB) where eliminating an HTTP request matters more than the 33% size bloat. Examples: small icons, decorative SVGs, tracking pixels. External files for larger content (images over 10 KB, fonts, videos) where caching benefits matter — separate files can be cached, CDN-distributed, and shared across pages. Modern HTTP/2 and HTTP/3 reduce the per-request overhead significantly, making data URIs less compelling than in HTTP/1.1 era. For most modern web development: use external files for everything except very small inline icons.

Why does Base64 use = at the end sometimes?

Padding. Base64 encoding produces output in groups of 4 characters representing 3 bytes. When input length isn't a multiple of 3 bytes, the last group is padded with '=' to reach 4 characters. 0-byte remainder: no padding. 1-byte remainder: '==' padding (output ends with ==). 2-byte remainder: '=' padding (output ends with =). The padding tells decoders where the original data actually ended. Some Base64 variants (URL-safe especially) omit the padding entirely — context determines how to handle.