Base64 Encoder & Decoder

Features

Everything a Developer Needs, Built In

Use cases

Where Developers Actually Use Base64

Privacy

Privacy-First by Architecture

ToolAdda's Base64 Studio is built so there is nothing to leak: encoding and decoding happen entirely inside your browser tab using standard Web APIs (TextEncoder, TextDecoder, atob, btoa, FileReader). No text, file, or image you process is ever transmitted to ToolAdda or any third party.

Important distinction: Base64 is not encryption and provides no confidentiality — it is a text-safe encoding, fully reversible by anyone. If you need to protect sensitive data, encrypt it first (e.g. AES) and use Base64 only to make the resulting ciphertext transportable as text.

Complete guide

The Complete Guide to Base64 Encoding

What Is Base64 Encoding?

Base64 is a binary-to-text encoding scheme defined by RFC 4648 that represents any sequence of bytes using only 64 printable ASCII characters: uppercase letters A–Z, lowercase letters a–z, the digits 0–9, and two extra symbols (+ and / in the standard alphabet). It exists to solve one specific problem: many systems — email, JSON, XML, URLs, older network protocols — were designed to carry plain text safely, but binary data (images, PDFs, compressed archives, raw cryptographic bytes) can contain byte values that those systems misinterpret, strip, or corrupt in transit. Base64 re-packages arbitrary bytes into a character set that is safe everywhere plain text is safe.

It's worth being precise about what Base64 is not: it is not compression (the output is roughly 33% larger than the input, never smaller), it is not encryption (there is no key and no secrecy), and it is not a hash (it's fully reversible, not a fixed-size fingerprint). It is simply a reversible re-encoding of bytes into text.

How Base64 Encoding Works, Step by Step

Base64 works on 3-byte (24-bit) groups of input, because 24 is the smallest number divisible by both 8 (bits per byte) and 6 (bits per Base64 character). Each 24-bit group is split into four 6-bit chunks, and each 6-bit chunk (a value from 0–63) is mapped to one character in the Base64 alphabet:

Input bytes (3 bytes / 24 bits):   01001101 01100001 01101110
Regrouped into 6-bit chunks:       010011 010110 000101 101110
Base64 character indices:          19     22     5      46
Base64 output:                     T      W      F      u
Result: "Man" → "TWFu"

When the input length isn't a multiple of 3 bytes, the final group is padded with zero bits and the output is padded with one or two = characters to signal how many "extra" bytes were added — this is why you'll often see Base64 strings ending in = or ==. URL-safe Base64 commonly omits this padding since the original length can be inferred by the decoder.

Base64 Encoding vs. Encryption vs. Hashing

These three concepts get confused constantly, and mixing them up is a genuine security risk (storing a Base64-encoded password and calling it "encrypted" is a real, recurring mistake). Here's the distinction:

When (and When Not) to Use Base64

Use Base64 when you need to move binary data through a text-only channel: embedding a small image directly in HTML/CSS as a Data URI, attaching a file to an email, sending binary payloads inside JSON, or storing a certificate in a plain-text config file. Avoid it when a native binary channel already exists and is more efficient — for example, uploading a large file via multipart/form-data or a binary API body is almost always better than Base64-encoding it into a JSON string first, both because you skip the 33% size penalty and because you avoid holding the entire encoded string in memory at once.

Base64 in APIs, JSON, XML, and HTML

JSON and XML have no native binary type, so any API that needs to transmit binary data as part of a structured document — a profile photo in a user object, a signature image in a form submission, a file attachment in a webhook payload — typically Base64-encodes it into a string field:

{
  "filename": "avatar.png",
  "contentType": "image/png",
  "data": "iVBORw0KGgoAAAANSUhEUgAA..."
}

In HTML and CSS, Base64 commonly appears inside a Data URI, which lets you inline an image, font, or icon directly into a document instead of linking to a separate file:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." alt="Inline icon" />

.icon {
  background-image: url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0i...);
}

This tool's File / Image tab generates exactly that Base64 payload — grab the output and wrap it in data:<mime-type>;base64, to build a Data URI by hand, or use the live preview to confirm the encoding round-trips correctly first.

UTF-8, Unicode, and a Common Base64 Bug

Base64 itself only knows about bytes — it has no concept of "characters." So before you can Base64-encode a piece of text, you first have to decide how that text becomes bytes, and that decision is a character encoding, almost always UTF-8 today. A surprisingly common bug happens when developers reach for JavaScript's native btoa()/atob() directly on a string: these functions only understand Latin1 (one byte per character) and throw or silently corrupt output on any character above code point 255 — which includes emoji, most non-Latin scripts, and even "smart quotes." The classic workaround, btoa(unescape(encodeURIComponent(str))), works but relies on the deprecated escape()/unescape() functions. This tool avoids all of that by using the modern TextEncoder/TextDecoder APIs internally, so text containing emoji, Hindi, Japanese, Arabic, or any other Unicode script encodes and decodes correctly every time.

URL-Safe Base64 Explained

The standard Base64 alphabet includes + and /, both of which are reserved characters inside URLs (+ often means "space," / separates path segments). Passing standard Base64 in a query string or filename without extra percent-encoding is a reliable way to break things. URL-safe Base64 (RFC 4648 §5) swaps + → - and / → _, and typically drops the = padding entirely, producing a string that's safe to use directly in URLs, filenames, and cookies. It's the variant used inside JWTs (JSON Web Tokens) for exactly this reason. This tool's URL-safe toggle switches the output alphabet on encode; decoding accepts both flavors automatically, so you never have to manually convert between them first.

Common Base64 Errors and How to Fix Them

• "Invalid character" errors — usually caused by line breaks, quotes, or whitespace accidentally copied along with the Base64 string (common when copying from an email client or a PDF).
• Wrong or missing padding — the decoded length isn't a multiple of 4; this tool's normalizer re-pads automatically, but hand-written decoders often don't.
• Mixing standard and URL-safe characters — a string containing both +// and -/_ is not valid in either alphabet and needs to be re-checked at the source.
• Double-encoding — Base64-encoding an already-encoded string produces a valid-looking but semantically wrong result; if decoded output still looks like Base64, decode it again.
• Encoding a string without specifying UTF-8 — see the Unicode section above; this is the single most common cause of "my emoji turned into garbage" bug reports.

Security Considerations

The most important security fact about Base64 is the one worth repeating: it provides no confidentiality. It's reversible by design, with no secret involved, so a Base64 string is exactly as sensitive as the plaintext it encodes — treat ZG9udCBzdG9yZSBzZWNyZXRzIGxpa2UgdGhpcw== the same as you'd treat the decoded sentence sitting in a log file. Storing passwords, API keys, or PII as "just Base64" and considering that secure is a real, documented class of vulnerability. If you need confidentiality, encrypt first with an authenticated cipher and Base64-encode the ciphertext only for transport.

Performance Considerations for Large Files

Because everything in this tool runs client-side, performance is bound by your device rather than a server queue — but a few practical limits still apply. Base64 output is always ~33% larger than input, so a 30 MB file becomes roughly 40 MB of text; browsers can comfortably handle this for typical file sizes, but very large files (several hundred MB) will use proportionally more memory and take longer to process. This tool processes file bytes in chunks to avoid call-stack limits on large arrays, and keeps live text processing debounced so typing stays responsive even with sizeable input.

Browser Compatibility

Every feature here — TextEncoder/TextDecoder, atob/btoa, the File and Blob APIs, drag-and-drop, and the Clipboard API — is a stable, broadly supported Web Platform feature available in all current versions of Chrome, Edge, Firefox, and Safari on both desktop and mobile. Copy-to-clipboard for images specifically requires the newer ClipboardItem API, which has slightly narrower support; where it's unavailable, the Download button works as a universal fallback.

Best Practices for Developers

• Always specify a character encoding (UTF-8) explicitly when converting strings to bytes before Base64-encoding — never rely on implicit Latin1 behavior.
• Use the URL-safe alphabet for anything that lands in a URL, filename, cookie, or JWT segment; use the standard alphabet for Data URIs and MIME email.
• Don't Base64-encode large binary payloads inside JSON if a native binary upload path (multipart, raw body) is available — you'll save both bandwidth and memory.
• Validate untrusted Base64 input before decoding it server-side, and always enforce a maximum decoded size to avoid memory-exhaustion attacks from an oversized string.
• Never treat Base64 as a security boundary — pair it with real encryption whenever confidentiality matters.

Why Choose ToolAdda's Base64 Studio

Keyboard Shortcuts

On macOS, use Cmd in place of Ctrl.

Explore more

Related Developer Tools