Base64 Encoder & Decoder

Introduction

Base64 Encoder & Decoder is a free online tool for converting text to Base64 and decoding Base64 back to text. Both operations happen in real time as you type, with no page reload or submit button. The tool runs entirely in your browser — nothing is sent to a server.

Two independent sections sit on the same page: one for encoding, one for decoding. Each has its own text area, upload zone, and action buttons, so you can work in both directions without switching modes.

What Is Base64?

Base64 is a way to represent binary data using only printable ASCII characters. It is not an encryption or compression scheme — its purpose is to make binary data safe to transport over systems that were designed to handle text.

How the Encoding Works

The Base64 alphabet uses 64 characters:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

The encoding process breaks the input into groups of 3 bytes (24 bits), then splits each group into four 6-bit values. Each 6-bit value (0–63) is mapped to one character in the alphabet.

Input:      F   o   o
Binary:     01000110 01101111 01101111
6-bit:      010001 100110 111101 101111
Decimal:    17     38     61     47
Base64:     R     b    9     v

"Foo" encodes to Rm9v.

Why 64?

64 was chosen because it is the largest power of two that uses only characters available in nearly all character sets (letters, digits, and two punctuation symbols). This makes Base64 reliable across email systems, JSON payloads, URLs, and other text-based channels that might mangle or reject non-ASCII bytes.

Each Base64 character carries 6 bits of information, compared to a byte's 8 bits. This 6-to-8 ratio is why encoded output is roughly 33% larger than the original input — a topic covered in more detail later.

When the Input Is Not a Multiple of 3 Bytes

If the last group has fewer than 3 bytes, padding is added. The encoder appends = characters to make the output length a multiple of 4:

• 1 byte remaining → 2 Base64 characters + ==
• 2 bytes remaining → 3 Base64 characters + =
• 3 bytes complete → 4 Base64 characters, no padding

For example, "Fo" (2 bytes) encodes to Rm8=.

A Note on What Base64 Is Not

Base64 is often confused with encryption because the output looks like gibberish. A quick decode reveals the original text with no key required. If you need to protect data, use a proper encryption algorithm (AES, ChaCha20, etc.) and then encode the encrypted bytes with Base64 for transport. Base64 alone provides no confidentiality.

Common Uses of Base64

Base64 appears in many everyday places on the web, often without users noticing it.

Data URIs

Modern browsers let you embed images, fonts, and other media directly in HTML or CSS using data: URIs:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">

The Base64-encoded image data lives inside the HTML file itself — no separate HTTP request needed. This is common for small icons, sprites, and web fonts, where the extra HTTP round-trip would cost more than the inline bytes.

However, Base64 data URIs are not always the best choice for larger assets. The 33% size overhead means a 100 KB icon becomes 133 KB of inline text, and the browser cannot cache it separately from the HTML page. Most sites use data URIs only for assets under a few kilobytes.

JWT and API Tokens

JSON Web Tokens use Base64url (the URL-safe variant) to encode the header, payload, and signature segments of a token. If you have ever inspected a JWT like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

each dot-separated segment is Base64url-encoded JSON. You can paste any segment into this tool's decode section to inspect its content.

Email Attachments (MIME)

Email was originally designed for 7-bit ASCII. To send binary attachments (images, PDFs, spreadsheets), the MIME standard encodes them as Base64. Your email client decodes them automatically when you open the message.

One detail that sometimes causes confusion: MIME Base64 conventionally wraps lines at 76 characters. If you extract Base64 data from an email source, it may contain embedded newlines. This tool's decoder handles newlines automatically — you can paste multi-line MIME Base64 without stripping the line breaks first.

PEM Certificates and Keys

SSL/TLS certificates and private keys are distributed in PEM format, which wraps Base64-encoded DER data between header and footer lines:

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----

PEM is essentially Base64 with a labeled wrapper. You can decode the Base64 body of a PEM file to inspect its raw DER content, though the result will be binary, not readable text.

HTTP Basic Authentication

The HTTP Basic auth header encodes username:password as Base64:

Authorization: Basic YWRtaW46c2VjcmV0

The string YWRtaW46c2VjcmV0 is the Base64 encoding of admin:secret. Base64 here is a serialization mechanism, not security — the credentials are trivially decoded by anyone who sees the header.

What Is a .b64 File?

A .b64 file is a plain text file whose entire content is a Base64 string. The .b64 extension is a naming convention that signals "this file holds Base64 data" rather than arbitrary text, source code, or a binary format.

You might encounter .b64 files when:

• Exporting encoded output from tools like this one
• Storing cryptographic keys or certificates in a portable text format
• Exchanging Base64 data between systems that use file-based workflows

Because .b64 files are plain text, you can open them in any text editor, inspect the content, or copy the string into a decoder. This tool accepts .b64 files in both the Encode and Decode sections via drag-and-drop or the file picker.

How It Works

The tool uses the browser's built-in Base64 functions with an extra layer for UTF-8 safety.

Core Conversion

JavaScript provides two native functions for Base64:

• btoa(input) — converts a string to Base64 (binary to ASCII)
• atob(input) — converts Base64 back to a string (ASCII to binary)

These functions only work with Latin-1 (ISO-8859-1) characters. If you pass a string containing Chinese, Japanese, emoji, or any character outside the Latin-1 range, btoa() throws a DOMException.

UTF-8 Safe Encoding

To handle all Unicode text correctly, the tool wraps the native functions:

function encode(text, urlSafe, noPad) {
  let utf8 = encodeURIComponent(text);
  let base64 = btoa(utf8);
  if (urlSafe) base64 = base64.replace(/\+/g, '-').replace(/\//g, '_');
  if (noPad) base64 = base64.replace(/=+$/, '');
  return base64;
}

function decode(base64) {
  let restored = base64.replace(/-/g, '+').replace(/_/g, '/');
  while (restored.length % 4 !== 0) restored += '=';
  let utf8 = atob(restored);
  return decodeURIComponent(utf8);
}

encodeURIComponent converts the text to UTF-8 percent-encoded form, which contains only ASCII characters that btoa can process. The decode path reverses this in the opposite order.

To see why this matters, try encoding the emoji "😊" with btoa directly — it throws an error. With the UTF-8 wrapper, it becomes J UmbKSA4bQ, which decodes back to 😊 correctly.

URL-Safe Input Handling

The decode function always runs two transformations before passing the string to atob:

1. Replace - with + and _ with / (undoing URL-safe encoding)
2. Append = padding if the string length is not a multiple of 4

This means you never need to toggle a setting on the decode side. Whether your input is standard Base64, URL-safe Base64, padded, or unpadded, the decoder handles it automatically.

Event Flow

When you type or paste into a text area, an input event listener fires. The scheduler buffers rapid keystrokes (debounced at approximately 16 ms to align with a single frame) and then runs the encode or decode function. The result appears in the output text area on the next screen refresh.

Standard Base64 vs URL-safe Base64

The two checkboxes in the Encode section correspond to two well-defined variants of Base64.

Standard Base64 (RFC 4648 §4)

Uses the full alphabet: A–Z, a–z, 0–9, +, /. This is the original form and works everywhere, except in places where + and / have special meaning.

URL-safe Base64 (RFC 4648 §5)

Replaces the two characters that cause problems in URLs:

Standard Base64 Pz4/Pj8+QA== becomes Pz4_Pj8- QA_ in URL-safe form (note: the padding = is also omitted in the example, though URL-safe can use padding too).

When to Use Each

The decode side in this tool automatically detects which variant was used, so you can paste either format without changing any settings.

A Common Misunderstanding

Some developers believe URL-safe Base64 is a different algorithm. It is not — only two characters in the alphabet change. Any standard Base64 decoder can be adapted by mapping - → + and _ → / before processing, which is exactly what this tool does on the decode side.

Padding in Base64

The = character at the end of a Base64 string is padding — it is not part of the encoded data.

Why Padding Exists

Base64 processes input in 3-byte groups. If the last group has fewer than 3 bytes, the encoder pads the output with = to make the total length a multiple of 4. This is required by some decoders and makes it possible to concatenate multiple Base64 strings without ambiguity.

What "Without Padding" Means

When you enable "Without padding," the encoder strips the trailing = characters from the output. For example:

• Input: Fo → Rm8= (padded) → Rm8 (unpadded)
• Input: Foo → Rm9v (no padding either way — exact multiple of 3)

Many modern systems accept unpadded Base64, and the tool's decoder always handles it. Toggle this option when the system you are feeding the output to does not require or does not want padding.

Interoperability Matrix

The decode section of this tool accepts all four combinations automatically:

There is no setting to adjust. The decoder normalizes the input before processing.

When Padding Is Required

Some systems strictly require padding, notably:

• Data URIs: data:image/png;base64,... — the browser's parser expects properly padded Base64.
• Older Base64 libraries: Some implementations reject unpadded input entirely.

If you are unsure whether the target system requires padding, keep it enabled (the default). Stripping padding is safe only when you control both the encoder and decoder.

Base64 vs Other Encoding Schemes

Base64 is one of several binary-to-text encoding schemes, each with different trade-offs in density, alphabet size, and use case.

Why Base64 Is the Most Popular

Base64 hits the sweet spot for most practical applications. Compared to hex — which doubles the input size — Base64's 33% overhead is significantly more efficient. Compared to Base85, Base64 is simpler to implement (every language has a built-in decoder), and its alphabet avoids the quoting issues that Base85 characters like " and \ can cause in some contexts.

When To Use Something Else

• Hex: When human readability and debugging matter more than size. A hex string like 4f6f is instantly recognizable as encoded data; b293 is less obvious as Base64.
• Base32: When case-insensitivity is required (e.g., spoken over the phone, printed on products). Base32 uses only uppercase letters and digits.
• Base85: When every byte of overhead matters in a constrained channel, and you control both ends of the pipeline.

For general-purpose web encoding, Base64 remains the right default. This tool follows that convention.

Performance and Size Considerations

Base64 is simple and universal, but it has real costs that matter when you work with larger data.

The 33% Overhead

Every 3 bytes of input become 4 bytes of output, a 4:3 ratio. In practice, including padding and line-wrapping overhead, the expansion is close to 37% for small inputs and settles at 33% for sufficiently large inputs.

Base64 and Compression

Gzip (or Brotli) compression of Base64 text is generally ineffective. Base64 output has a uniform character distribution — each of the 64 characters appears with roughly equal frequency — which eliminates the patterns that compression algorithms exploit. A compressed Base64 string is often only 5–10% smaller than the uncompressed form, compared to the 60–80% reduction achievable with the original binary.

This means:

• Do not Base64-encode data before compressing it. Compress first, then encode if needed.
• Do not rely on transport-level compression (e.g., HTTP gzip) to offset the Base64 overhead. It will not.

When Not To Use Base64

Base64 makes sense when you need to fit binary data into a text-only channel. If the channel supports binary transfer natively, skip Base64:

• File uploads: Use multipart/form-data with raw binary, not Base64 in JSON. The file arrives at the server 33% larger and takes longer to upload.
• Database storage: Store binary data as BYTEA (PostgreSQL), BLOB (MySQL/SQLite), or varbinary (MSSQL) instead of Base64 text.
• Inter-service API calls: Use gRPC, Thrift, or MessagePack with binary fields rather than Base64-encoded JSON strings.

For text payloads (JWT payloads, HTML content, email bodies), the overhead is negligible and the convenience of Base64 is worth the trade-off.

Caching Implications

When you embed a Base64 data URI in HTML or CSS, the encoded content becomes part of the page resource. The browser cannot cache that data URI independently — any change to the page invalidates it. A separate image file requested via <img src="icon.png"> can be cached across pages with a far-future Cache-Control header. For assets larger than a few kilobytes, separate files almost always perform better.

Common Pitfalls and Misconceptions

Base64 is simple, but several recurring misunderstandings cause real-world errors.

Base64 Is Not Encryption

This is the most common misconception. Because Base64 output looks like random characters, many developers assume it provides some level of protection. It does not. Decoding requires no key or secret. Treat any Base64 string as publicly readable text.

If you see a service storing passwords or API keys as Base64, treat that as a security issue — the data is stored in plain sight.

Case Sensitivity

The Base64 alphabet distinguishes uppercase and lowercase letters:

• Uppercase: A–Z (values 0–25)
• Lowercase: a–z (values 26–51)

A typo like R vs r changes the decoded value completely. If your decoded output looks wrong, check for case errors in the input.

MIME Line Wrapping

MIME-encoded email attachments wrap the Base64 body at 76 characters per line:

SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdCBvZi BiYXNlNjQgZW5jb2Rpbmcu
VGhpcyBpcyB0aGUgc2Vjb25kIGxpbmUu

Not all Base64 decoders handle these embedded newlines. This tool does — paste multi-line MIME Base64 directly without pre-processing. A decoder that does not handle newlines will produce a garbled result or an error.

Hidden Whitespace

Copying text from emails, PDFs, or web pages can introduce invisible whitespace characters (spaces, tabs, zero-width spaces, non-breaking spaces). These are not valid Base64. If a valid-looking Base64 string fails to decode, paste it into a plain text editor first to check for hidden characters, or re-copy from the source.

Concatenation of Padded Strings

Two padded Base64 strings concatenated directly do not necessarily decode correctly. The padding = belongs to the last group of each string, and concatenation can create ambiguous boundaries. This is by design — padding prevents ambiguity for individual strings. For multi-part data, handle each part separately.

Usage

Using the Base64 Encoder & Decoder requires no setup, registration, or account.

Encoding Text to Base64

1. In the Base64 Encode section, type or paste your text into the input text area.
2. The output area updates automatically with the encoded result.
3. Optionally, toggle URL-safe to use the web-safe variant, or Without padding to strip trailing = characters.
4. Click Copy to copy the encoded text to your clipboard, or Download Base64 to save it as a .b64 file.

Decoding Base64 to Text

1. In the Base64 Decode section, paste a Base64 string into the input area.
2. The decoded text appears in the output area instantly.
3. If the input is not valid Base64, an error message is shown instead.
4. Click Copy or Download to save the decoded result.

Using File Upload

• Encode section: drop a .txt file onto the upload zone to load its content for encoding.
• Decode section: drop a .b64 or .txt file to load Base64 content for decoding.

The file content is read, placed into the input text area, and processed immediately.

Tutorial

Scenario: You are building a web application that communicates with an API. The API expects the request payload to include a short text field encoded as URL-safe Base64 without padding. You need to encode your text, verify the output, and confirm the API accepts it. Later, you receive a response from the same API with a Base64-encoded field that you need to decode.

This tutorial walks through the entire round-trip.

Part 1: Encoding

1. Open the Base64 Encoder & Decoder in your browser. You see two sections side by side — Encode on the left, Decode on the right.

2. In the Encode input area, type the following text:

   Hello, API server. This is my payload.
   

   The output area immediately shows the standard Base64 encoding. The result starts with SGVsbG8sIEFQ. So far so good.

3. The API specification requires URL-safe Base64 without padding. Enable both URL-safe and Without padding checkboxes. Watch the output change:

   • + characters (if any) become -
   • / characters become _
   • Trailing = characters disappear

   For this particular input, there are no + or / characters in the Base64 output, so the URL-safe checkbox has no visible effect. But the padding checkbox does strip the trailing ==.

4. Click Copy to copy the encoded result to your clipboard. Paste it into your API request payload.

Part 2: Decoding

5. The API responds with a JSON payload containing a Base64-encoded field:

   {
     "status": "ok",
     "message": "eyJzdWIiOiAiMTAwMSIsICJuYW1lIjogIkFQSSBHYXRld2F5In0="
   }
   

6. Copy the value of message and paste it into the Decode input area.

   The output area instantly shows the decoded text:

   { "sub": "1001", "name": "API Gateway" }
   

7. The JWT-style JSON payload is now readable. If the API had used URL-safe Base64 (no + or / in the string, or with - and _ instead), the decoder would handle it automatically — no checkbox to toggle.

Part 3: File-Based Workflow

8. Suppose you need to send the encoded payload to a colleague who prefers files. Click Download Base64 in the Encode section. Your browser's Save As dialog opens, suggesting download.b64 as the filename. Save it.

9. Your colleague receives the file and opens this same tool. They drag download.b64 onto the Decode section's upload zone. The file content appears in the input area, and the decoded text appears immediately.

This round-trip — encode with options → copy or download → decode with automatic detection — covers the most common real-world workflow. The tool handles all the normalization so you do not have to think about character variants or padding rules.

Pro Tips

• Encode and decode simultaneously: The two sections are independent. You can type text in the Encode section and paste a separate Base64 string in the Decode section at the same time. Use this to compare input and output across both directions side by side.

• URL-safe for JWTs: When working with JWT tokens, always enable URL-safe mode. JWT segments use the URL-safe variant (RFC 7515). If you paste a JWT segment into the decode section, the tool detects the URL-safe characters automatically.

• Trim whitespace before pasting: Some sources of Base64 data include trailing newlines or spaces. The decoder handles trimmed input best. If you see a "Invalid Base64 string" error, check whether the pasted text has extra whitespace.

• Download for large output: For long Base64 strings, use the Download buttons instead of Copy. The native Save As dialog lets you choose where to save the file, and the result is saved as a .b64 or .txt file that you can transfer or archive.

• Upload as an alternative to typing: If you already have a file containing the text or Base64 data, drag it onto the upload zone. This is faster than opening the file, selecting all, copying, and pasting — especially for large files.

• Decode first to check format: If you receive a Base64 string and are unsure whether it contains text or binary data, paste it into the decode section. If the output is readable text, you are done. If it contains garbled characters or replacement glyphs ( ), the original source was likely binary (an image, PDF, or other non-text format).

Alternatives

Several other ways to encode or decode Base64 exist, each with different trade-offs.

For encoding or decoding Base64 text with privacy, real-time feedback, and no command-line knowledge required, this tool offers the best user experience.

Data Privacy

The Base64 Encoder & Decoder processes every character entirely in your browser. No text you enter is transmitted to any server, stored in any database, or logged in any system.

All conversion is performed using JavaScript's native btoa() and atob() functions within the browser's memory. The page includes no analytics scripts, no tracking pixels, and no third-party embeds. No cookies, localStorage, or sessionStorage entries are created or read.

After the initial page load, the tool functions fully offline. You can disconnect from the internet and continue encoding and decoding without interruption. Verify this by using the tool in airplane mode or by inspecting network activity in your browser's developer tools — no requests leave your device after the page loads.

Troubleshooting

Technical Specifications

• Core Algorithm: btoa() / atob() wrapped with encodeURIComponent / decodeURIComponent for UTF-8 safety
• Standard: RFC 4648 §4 (standard Base64), RFC 4648 §5 (URL-safe Base64)
• Input Handling: Automatic URL-safe character conversion (- → +, _ → /) and padding normalization on decode
• Real-time Processing: input event listener on text areas, debounced at approximately one frame (16 ms)
• File I/O: FileReader API for upload, showSaveFilePicker (File System Access API) with <a download> fallback
• Download Formats: .b64 (encoded), .txt (decoded)
• Upload Formats: .txt (encode section), .b64 / .txt (decode section)

Performance Benchmarks

Measured on a 2020 mid-range laptop (Chrome 120). Performance scales linearly with input size. For typical text payloads under 100 KB, the conversion is effectively instantaneous.

Browser Compatibility

showSaveFilePicker requires Chromium-based browsers (Chrome, Edge, Opera, Samsung Internet). On Firefox and Safari, the download falls back to the <a download> method automatically.

Privacy & Security

• Zero data transmission: all text processing occurs in the browser's memory
• No cookies, localStorage, or sessionStorage used
• No analytics or tracking scripts on the tool page
• Fully functional in offline mode after initial page load
• No registration, login, or API keys required

Features

• Encode text to Base64 and decode Base64 back to text with real-time conversion
• URL-safe mode using -_ instead of +/ for web-friendly Base64 (RFC 4648 §5)
• Without padding option to strip trailing equals signs (RFC 4648 §3.2)
• Built-in explanation of the Base64 encoding scheme and .b64 file format
• Upload .txt and .b64 files with drag-and-drop support
• Download results as .b64 or .txt files with native Save As dialog
• Fully client-side — no server uploads, works offline

Frequently Asked Questions