Base64 Encoder / Decoder

Base64 Encoder and Decoder — Convert Text and Binary Data to Base64 Online

Every developer who has spent time working with APIs, email systems, or web-based data transfer has run into Base64 at some point — usually without realizing it at first. You see those long strings of letters, numbers, plus signs, and forward slashes in a JWT token, an embedded CSS image, or an Authorization header, and eventually the pattern clicks: that is Base64. It is everywhere in modern software, quietly doing the work of translating binary data into something text-based systems can handle without breaking.

That is exactly what this tool does. Paste any text or data into the input field, pick encode or decode, and get your result instantly. Everything runs locally in your browser using JavaScript — nothing leaves your machine, no server is involved, and there is no waiting for a round trip.

What Base64 Actually Is

Base64 is a binary-to-text encoding scheme defined in RFC 4648. It takes raw binary data — arbitrary bytes that can be anything from printable letters to invisible control characters — and maps that data into a fixed set of 64 printable ASCII characters: A through Z, a through z, 0 through 9, plus (+) and slash (/). That set is safe to transmit through any system that handles text, which is the entire point.

The math is straightforward. The encoder reads three input bytes at a time — 24 bits total — and splits those 24 bits into four groups of 6 bits each. Each 6-bit group maps to one of the 64 characters in the alphabet. Since 6 bits can represent values from 0 to 63, every possible combination has a character assigned to it. When the input length is not a multiple of three, padding characters (=) are appended to the output so its length is always a multiple of four. That is why you see one or two equals signs at the end of Base64 strings — they are not part of the data, they are structural filler.

The name "Base64" comes directly from the 64-character alphabet. It is not a cipher, not an algorithm with a secret key, and not something that requires computation beyond a simple lookup table. It is a format conversion — binary in, text out, and back again with no loss.

Why It Exists: The Text-Only Problem

Most of the protocols and systems built in the early decades of networking were designed exclusively for ASCII text. SMTP (the email protocol), HTTP headers, HTML attributes, JSON fields, XML content, command-line interfaces — all of them assume they are carrying printable characters. Send a raw binary byte through any of these systems and you get corruption, truncation, or outright rejection. The byte 0x00 (null) will terminate a C string. Bytes above 0x7F behave unpredictably across different character encodings. Binary data simply cannot traverse text-based infrastructure safely.

Base64 was created to solve that exact problem. Encode the binary as text, pass it through whatever text-only channel you need, and decode it on the other side. The data arrives intact. The encoding overhead is predictable and acceptable. The process is standardized across every programming language and platform, which means a Base64 string produced by a Go service can be decoded by a JavaScript client, a Python script, or a Java application with zero compatibility issues.

Real-World Use Cases You Will Encounter

Data URIs for inline assets: Small images — favicons, icons, decorative elements, simple SVGs — can be Base64-encoded and embedded directly in HTML or CSS using the data: URI scheme. Instead of referencing an external file and making an HTTP request, the image data sits right in the markup: background-image: url('data:image/png;base64,iVBOR...');. This eliminates a network round trip, which matters for tiny assets on high-latency connections. The trade-off is a 33% size increase and the inability to cache the asset independently, so anything larger than about 10 KB is better served as a separate file.

API authentication headers: HTTP Basic Authentication sends credentials as Authorization: Basic dXNlcjpwYXNz, where the string after "Basic" is the Base64 encoding of username:password. OAuth tokens, API keys passed in custom headers, and Bearer tokens in various authentication flows all use Base64 or Base64url encoding at some point in their lifecycle. This is a common stumbling block for developers who try to "decrypt" a Basic auth header and discover it decodes to readable text — Base64 provides no confidentiality.

Email attachments (MIME): The MIME standard that handles email attachments depends entirely on Base64. When you attach a PDF, an image, or a Word document to an email, your mail client Base64-encodes the binary file before transmission. The recipient's client decodes it back. SMTP was designed for 7-bit ASCII text in the 1980s; Base64 is the bridge that makes binary attachments possible over that infrastructure.

JSON payload file transfer: When a REST API needs to include binary data inside a JSON body — a profile photo upload, a scanned document, a file attachment in a ticketing system — Base64 encoding is the standard approach. The binary gets encoded as a string field in the JSON, transmitted, and decoded on the server. This is common in mobile app backends, receipt capture systems, and document management APIs.

JWT tokens: JSON Web Tokens consist of three dot-separated sections, each Base64url-encoded: the header (algorithm and token type), the payload (claims and metadata), and the signature. The encoding is what allows a JWT to be safely passed in URLs, HTTP headers, and form fields. Pasting any JWT into a Base64 decoder immediately reveals its contents — the header and payload are not encrypted, only encoded.

Cryptographic material in PEM format: SSL/TLS certificates, RSA private keys, SSH public keys, and other cryptographic data are stored as Base64-encoded blocks between header lines like -----BEGIN CERTIFICATE-----. The PEM format exists because it lets you store binary cryptographic data as plain text — in configuration files, environment variables, email, or version control systems that only handle text.

The 33% Size Overhead — When It Matters

Base64 encoding increases data size by approximately one-third. The math is fixed: 3 input bytes become 4 output characters, and since each character is one byte in ASCII, you end up with 4 bytes representing 3 bytes of original data. A 1 KB file becomes roughly 1.33 KB. A 3 MB image becomes roughly 4 MB.

For small assets — under about 10 to 15 KB — this overhead is usually worth the trade-off, especially when it eliminates an HTTP request. For larger files, the overhead compounds into a real performance penalty. A 10 MB video encoded to Base64 becomes over 13 MB of text that also has to be parsed as a string before it can be used. For anything beyond small icons and thumbnails, serving binary data directly (as a file upload, a binary response, or a CDN-hosted asset) is almost always the better choice.

Base64 vs. Base64url — Why the Variant Exists

Standard Base64 uses two characters — plus (+) and forward slash (/) — that have special meaning in URLs. The plus sign is interpreted as a space in URL query strings, and the forward slash is a path separator. If you put a standard Base64 string into a URL parameter, the receiving system will misinterpret it.

Base64url (also called URL-safe Base64) was created to fix this. It replaces + with - (hyphen) and / with _ (underscore), producing a character set that is safe in any URL context without percent-encoding. It also typically omits the = padding characters. JWT tokens, OAuth access tokens, and any Base64 data that will appear in URLs or filenames should use the Base64url variant. The encoding and decoding logic is otherwise identical.

Base64 Is Not Encryption — A Critical Distinction

This point cannot be stated clearly enough: Base64 is a reversible encoding, not a form of encryption. Anyone who has the Base64 string can decode it instantly. No key is needed, no password, no secret. If you Base64-encode a password and send it in an HTTP header, it is just as visible to anyone intercepting the traffic as if you had sent the password in plain text. Base64 provides zero confidentiality.

A common mistake in legacy systems is storing user passwords as Base64-encoded strings in a database, under the mistaken belief that this protects them. It does not. Base64 is a format converter, not a security mechanism. If you need to protect data, use proper encryption: HTTPS/TLS for data in transit, AES or similar symmetric encryption for data at rest, and purpose-built password hashing functions (bcrypt, Argon2) for credential storage. Base64 can be the final step in an encoding pipeline — encoding data that has already been encrypted — but it adds no protection on its own.

Working with Base64 in Code

Every major language has built-in or standard-library support for Base64. In JavaScript: btoa() to encode and atob() to decode (browser). In Python: base64.b64encode() and base64.b64decode() from the standard library. In PHP: base64_encode() and base64_decode(). In Java: java.util.Base64. In Go: the encoding/base64 package. In Ruby: Base64.encode64() and Base64.decode64().

One thing to watch out for: JavaScript's btoa() function only accepts strings where every character has a code point below 256 (essentially Latin-1). If you try to encode a string containing emoji or non-Latin characters, it throws an error. The fix is to first encode the string to UTF-8 bytes using new TextEncoder().encode(text), then Base64-encode those bytes. Most other languages handle UTF-8 natively without this extra step.

Frequently Asked Questions About Base64 Encoding