UtilitiesHub

Base64 Encoder / Decoder


Explore More

Go straight to the formatter, validator, encoder, generator, or developer utility you need.

Coding Tools

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

Base64 is one of those encoding schemes that's ubiquitous in software development but rarely fully understood. If you've worked with REST APIs, embedded images in CSS, handled email attachments, read JWT tokens, or worked with SSL certificates and cryptographic keys, you've already encountered Base64 — it's just that it usually happens behind the scenes. Understanding what it is, why it exists, and when to use it (and when not to) is foundational knowledge for any developer working with web systems, APIs, or data serialization.

This tool lets you encode any text or data to Base64 and decode any Base64 string back to its original form, directly in your browser. Nothing is sent to any server — all encoding and decoding runs locally in JavaScript.

What Base64 Actually Is — and Why It Exists

Base64 is a binary-to-text encoding scheme. It converts binary data — bytes that can hold values from 0 to 255, many of which are non-printable control characters — into a string of printable ASCII characters that can safely be transmitted and stored anywhere text is accepted.

The encoding works by reading three bytes at a time (24 bits total), dividing those 24 bits into four groups of 6 bits each, and mapping each 6-bit value (0–63) to one of 64 printable characters: A–Z, a–z, 0–9, +, and /. The name "Base64" comes directly from this 64-character alphabet. When the input length isn't divisible by three, one or two = padding characters are appended to make the output a multiple of four characters.

Base64 exists because many protocols and systems were designed to handle only printable ASCII text — not arbitrary binary data. SMTP (email), HTTP headers, HTML attributes, JSON fields, XML content, and many other text-based systems can't reliably carry raw binary bytes. Base64 provides a universal bridge: encode binary as text, pass it through any text-based system, decode it back on the other side.

Real-World Uses of Base64 in Web Development

Embedded images in HTML and CSS: Small images — icons, logos, decorative elements, inline SVGs — can be Base64-encoded and embedded directly as data URIs in HTML or CSS, eliminating the extra HTTP request. A background image in CSS becomes background-image: url('data:image/png;base64,...');. This is most useful for very small images (a few KB); larger images should be served as separate files because the size overhead and inability to be cached independently make embedding counterproductive.

API file transmission: When a REST API needs to transmit binary data — an image, a PDF, a file attachment — within a JSON payload, Base64 is the standard approach. The binary file is encoded to a Base64 string, included in the JSON as a string field, transmitted, and decoded on the server back to binary for storage or processing. Mobile app photo uploads, document scanning APIs, and receipt capture workflows all commonly use this pattern.

Email attachments: SMTP, the protocol that carries email, was originally designed for 7-bit ASCII text. Email attachments — PDFs, images, Word documents — are Base64-encoded by your email client before transmission and decoded by the recipient's client. The MIME multipart format that handles attachments depends on Base64 for this binary-to-text conversion.

Cryptographic keys and certificates: PEM files — the format used for SSL/TLS certificates, RSA private keys, and other cryptographic material — store their data as Base64-encoded content between header lines like -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. This makes cryptographic keys safe to paste into text files, email, environment variables, and configuration management systems.

JWT tokens: JSON Web Tokens use URL-safe Base64 (Base64url) encoding for their header and payload sections. The three dot-separated sections of a JWT are each Base64url-encoded JSON objects — which is why you can paste a JWT into a decoder and immediately read the claims inside it.

The 33% Size Overhead

Base64 encoding increases data size by approximately 33%. The reason: every 3 bytes of binary data become 4 Base64 characters. Since ASCII characters are also bytes, you're using 4 bytes to represent what was originally 3 bytes — a 33% increase. A 3 MB image becomes approximately 4 MB when Base64-encoded. For small assets (under 10–15 KB), this overhead is usually acceptable given the benefit of eliminating an HTTP request. For larger files, the overhead is significant enough that serving binary data directly is almost always preferable.

Standard Base64 vs. URL-Safe Base64

Standard Base64 uses + and / as two of its 64 characters. Both of these characters have special meaning in URLs — + is interpreted as a space in URL query strings, and / is a path separator. This makes standard Base64 strings unreliable when used in URLs or filenames.

URL-safe Base64 (also called Base64url) replaces + with - (hyphen) and / with _ (underscore), producing strings that are safe in URL components without percent-encoding. It also typically omits the padding = characters. JWT tokens, OAuth tokens, and any Base64 data intended for use in URL parameters or filenames should use URL-safe Base64.

Base64 Is Not Encryption

This distinction is important enough to state explicitly: Base64 is a reversible encoding scheme, not encryption. Any Base64 string can be decoded to its original form by anyone with access to the string — no key or password is needed. Encoding sensitive data in Base64 provides zero confidentiality. If you Base64-encode a password or API key and include it in a request over HTTP, it's as readable to an observer as if you'd sent it in plain text.

Base64 is a format converter, not a security mechanism. Always use proper encryption (HTTPS/TLS for data in transit, AES for data at rest) when handling sensitive data. Base64 may be used as the final encoding step for encrypted ciphertext or for encoding data that's already been signed or protected — but it adds no protection on its own.

Frequently Asked Questions About Base64 Encoding

These are padding characters. Base64 requires output length to be a multiple of four. If your original data doesn't divide evenly into groups of three bytes, padding "=" characters are added to reach the nearest multiple of four. One or two = at the end is normal and expected. Most Base64 decoders automatically handle padding, so you don't need to worry about removing it manually.
Technically yes, but practically no. Encoding a 1GB file to Base64 creates a ~1.3GB string, consuming massive memory and CPU. For large files, keep them in binary format and use direct file I/O. If you absolutely must transmit a large file over text protocols, use streaming Base64 encoding in chunks, or better yet, use proper binary transfer protocols like FTP or SFTP.
Yes, standard Base64 encoding is standardized in RFC 4648 and produces identical output regardless of programming language. A string encoded in Python will decode identically in JavaScript, PHP, or Java. This cross-language consistency is one of Base64's biggest strengths for interoperability.
`btoa()` is JavaScript's browser-based encoding function; `base64_encode()` is PHP's version. They produce identical Base64 output—the function names are just language conventions. Both support the same Base64 standard. Where they differ is in Unicode handling: `btoa()` has limitations with characters beyond ASCII, while PHP's version handles UTF-8 without issues (after proper conversion).
Yes, using the data: URI scheme (``), though email client support varies. Many desktop email clients support data: URIs, but some email providers (Gmail, Outlook) strip them for security reasons. For maximum email compatibility, host images on a server and link to them via HTTP/HTTPS instead of embedding Base64.
Browsers can typically handle Base64 strings up to several megabytes without major issues, but performance degrades. URL length limits vary by browser (typically 2KB for ancient IE, 2MB+ for modern browsers), so huge Base64 data URIs in URLs may fail. For large data, use form uploads or API requests instead of Base64 data URLs.
Absolutely. Base64 is a lossless encoding—decoding a Base64 string reproduces the exact original binary data, byte-for-byte. Every bit of information is preserved. This is why Base64 works reliably for transmitting critical data like cryptographic keys and files.
Convert text to UTF-8 bytes first, then Base64-encode those bytes. In JavaScript, use `new TextEncoder().encode(text)` then encode the resulting Uint8Array. In Python, use `text.encode('utf-8')` before encoding. Most modern libraries handle this automatically, but it matters when working with multilingual text that extends beyond ASCII.
Often they do—databases with BLOB support, cloud storage like S3, and modern filesystems all handle binary natively and more efficiently. Base64 is used when you're forced into text-only systems (old databases with TEXT-only fields, text-based configuration files, email protocols) or need maximum compatibility across different platforms and systems.
Base64 is more relevant than ever. While binary formats have improved, APIs, JSON payloads, email systems, and countless integrations still rely on Base64 daily. OAuth tokens, JWT credentials, and modern microservices often use Base64-encoded data. It's a foundational technology that won't disappear soon.