What Is Base64 Encoding? Base64 Encoder & Decoder Explained

September 17, 2026

If you've worked with APIs, embedded an image directly in CSS, or debugged a JWT, you've run into Base64 — usually as a block of text ending in one or two = characters that looks vaguely like gibberish. It's one of the most common encodings in software development, and also one of the most misunderstood: plenty of developers treat it as a form of security, which it isn't. This guide explains what Base64 actually is, how it works, where it's genuinely useful, and how to use Kravoy's Base64 Encoder/Decoder to convert between the two.

What Is Base64?

Base64 is a way of representing binary data — raw bytes — using only 64 printable ASCII characters: A–Z, a–z, 0–9, plus + and / (with = used for padding at the end). It's not a compression format, and it's not encryption. It's purely a way to take data that might contain any byte value, including ones that don't print or transmit cleanly, and re-represent it using characters that are guaranteed to survive being copied, pasted, typed into a text field, or sent through systems that only expect plain text.

Why Base64 Exists

Base64 exists because a lot of the infrastructure the internet was built on — email protocols, older text-based transmission systems, URL query strings, JSON — was designed to handle text, not arbitrary binary data. Some bytes have special meaning in these systems (a null byte can terminate a string early, certain byte sequences can be misinterpreted as control characters, non-ASCII bytes can get mangled by systems that assume a specific text encoding). Rather than trying to make every transmission system binary-safe, Base64 sidesteps the problem: it converts binary data into a restricted set of characters that every one of these systems already handles correctly.

This is why Base64 shows up constantly in email attachments, embedded images, API payloads, and authentication tokens — anywhere binary or special data needs to travel safely through a text-oriented channel.

How Base64 Encoding Works, Conceptually

You don't need the bit-level math to use Base64 effectively, but the core idea is worth understanding: Base64 takes the input data 3 bytes (24 bits) at a time and re-slices those 24 bits into four 6-bit chunks instead. Since 6 bits can represent exactly 64 different values (2⁶ = 64), each 6-bit chunk maps directly to one of the 64 Base64 characters. That's where the name comes from — it's a base-64 numbering system, the same way binary is base-2 and hexadecimal is base-16.

Two practical consequences fall out of this directly:

Base64 output is always about 33% larger than the input. Every 3 bytes of input becomes 4 characters of output, a 4:3 size increase — worth knowing before Base64-encoding something large, since it isn't free.
Padding (=) appears when the input length isn't a multiple of 3 bytes. If there's 1 byte left over, the output ends in ==; if there are 2 bytes left over, it ends in a single =. This is just the encoding filling in the last incomplete 6-bit group, not an error.

A Simple Text Example

Encoding the plain text Hello in Base64 produces:

Hello  →  SGVsbG8=

And a longer, more realistic example — encoding Kravoy — free online tools:

Kravoy — free online tools  →  S3Jhdm95IOKAlCBmcmVlIG9ubGluZSB0b29scw==

Notice the output is longer than the input and made up entirely of letters, digits, and a trailing = — exactly the "safe for any text channel" property Base64 is designed to guarantee. There's no key involved, no randomness, and no configuration: the same input always produces the same output, every time, which is a big part of why it isn't suitable as a security mechanism (more on that below).

Base64 Decoding

Decoding simply reverses the process: the Base64 text is split back into its 6-bit groups, those groups are re-assembled into the original 8-bit bytes, and any padding is stripped off. Decoding SGVsbG8= gives you back exactly Hello — nothing is lost or approximated, since Base64 is fully reversible by design.

One common source of decode errors: Base64 text that's been altered even slightly — a missing character, extra whitespace inserted by a text editor, or a truncated copy-paste — will usually fail to decode cleanly or produce corrupted output, since every character in the string is load-bearing for reconstructing the original bytes.

Encoding Files to Base64

Base64 isn't limited to text — it works on any binary data, including images, PDFs, audio, or any other file type, since Base64 operates on raw bytes regardless of what those bytes represent. A small image file, for instance, can be fully represented as a single long Base64 string, which is exactly how the Data URL technique (below) embeds images directly inside HTML or CSS instead of linking to a separate file.

The tradeoff is the same 33% size increase mentioned earlier — Base64-encoding a 300KB image produces roughly 400KB of text, which matters if you're embedding several images this way on a single page.

Data URLs

A Data URL is a way to embed a file's content directly inside an HTML attribute, CSS property, or JSON payload, using Base64, instead of pointing to an external file with a normal URL. It follows this format:

data:[mime-type];base64,[base64-encoded-data]

For example, a small PNG icon embedded directly in an <img> tag looks like:

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

This avoids a separate HTTP request for that image, which can be useful for small, frequently-used assets like icons — but it also means the encoded data is duplicated inline everywhere it's used, and can't be cached separately by the browser the way a linked file can. It's a genuinely useful technique for small assets, not a general replacement for normal image hosting.

Common Developer Use Cases

API Payloads

Many APIs need to send binary data (an image upload, a file attachment, a cryptographic signature) inside a JSON request or response body — and JSON is a text format that doesn't support raw binary directly. Base64-encoding the binary data lets it travel safely as a JSON string field, at the cost of the usual ~33% size overhead.

Authentication Tokens

JWTs (JSON Web Tokens) use Base64 (specifically a URL-safe variant, Base64URL) to encode their header and payload sections into a compact, URL-safe string. This is exactly the case where the "Base64 isn't encryption" distinction matters most, covered in detail below — a JWT's payload is readable by anyone who has the token, not hidden from them.

Email and Data Transmission

Email attachments have used Base64 (via the MIME standard) for decades, since the underlying SMTP protocol was originally designed for 7-bit ASCII text and can't reliably carry arbitrary binary data. Any file you've ever attached to an email has, at some point in transit, existed as a Base64-encoded block inside the message.

Embedding Small Assets

Beyond images in HTML/CSS, Base64 shows up for embedding small binary blobs in config files, environment variables, and command-line arguments — anywhere a system expects a plain text value but the actual data isn't text.

When Base64 Is Useful

Transmitting binary data through a text-only channel (JSON APIs, email, URL parameters).
Embedding small, static assets directly in HTML, CSS, or JSON to avoid an extra network request.
Safely representing data in formats or protocols that don't support arbitrary bytes.
Compactly encoding structured data in tokens like JWTs, where the format needs to be URL-safe and text-based.

When Base64 Should NOT Be Used

As a substitute for encryption. Covered in detail below — this is the single most important thing to understand about Base64.
For large files where size matters. The ~33% overhead adds up fast; if you're transferring large binary files, a direct binary transfer (or a normal file upload/multipart form) is almost always more efficient than Base64-encoding them into a text payload.
As a way to obscure sensitive data "for now.” Base64-encoded secrets in config files, source code, or version control are just as exposed as if they were written in plain text — anyone who finds them can decode them instantly, with no special tools or knowledge required.
For data integrity checking. Base64 doesn't detect corruption or tampering — that's what checksums and hashes are for, not encoding.

Base64 Is Not Encryption

This is worth stating plainly because it's such a common and consequential misunderstanding: Base64 is encoding, not encryption, and it provides zero security. Encoding and encryption solve completely different problems:

Encoding (what Base64 does) transforms data into a different representation for compatibility — no key is involved, the transformation is fully public and reversible, and anyone can decode it instantly using any Base64 decoder, including the one on this page.
Encryption transforms data using a secret key specifically so that it cannot be reversed without that key — this is what actually protects sensitive data from being read by someone who intercepts it.

If you Base64-encode a password, an API key, or any other secret and put it somewhere (a config file, a URL, a public repository), you have not protected it in any way — you've simply made it slightly less readable at a glance, which is often worse than storing it in plain text, because it can create a false sense of security. A JWT's payload, for example, is Base64-encoded, not encrypted — anyone who intercepts a JWT can read its contents (like a user ID or role) directly, which is exactly why sensitive data shouldn't be placed in a JWT payload, and why JWTs rely on a separate cryptographic signature to verify they haven't been tampered with, not to hide their contents. If you actually need to keep data confidential, use real encryption (like AES) with a properly managed key, not Base64.

How to Use Kravoy's Base64 Encoder/Decoder

Kravoy's Base64 Encoder/Decoder runs entirely in your browser — nothing you paste or upload is sent to a server, which matters if you're working with anything even mildly sensitive. It handles both text and files:

For text: switch to the Text tab, choose Encode or Decode, and type or paste directly into the left panel. The result updates instantly in the right panel — no button click needed.
For files: switch to the File/Image tab and click to choose any file — an image, PDF, or any other document. It's converted into a full Base64 data URL, ready to paste into HTML, CSS, or a JSON payload. If the file is an image, a live preview renders directly from the encoded data, a quick way to confirm the encoding worked correctly.
To reverse a file: paste a Base64 string (or a full data URI) into the "Base64 → File" panel, set a filename, and click Download File to reconstruct and download the original binary file.
Copy the result using the copy icon (or Ctrl+Shift+C) for text output, ready to paste wherever you need it.

FAQ

Is Base64 the same as encryption?
No. Base64 is a reversible encoding scheme with no key and no security guarantee — anyone can decode it. Encryption requires a secret key to reverse and is what actually protects data.

Why does Base64 output end in = signs?
That's padding, added when the input length isn't an exact multiple of 3 bytes. It's a normal part of valid Base64, not an error.

Why is my Base64 output longer than the original text?
Base64 always increases size by roughly 33%, since every 3 bytes of input becomes 4 characters of output. This is expected, not a bug.

Can I Base64-encode any type of file?
Yes — Base64 works on any binary data, including images, PDFs, audio, and documents, since it operates on raw bytes rather than a specific file format.

Is it safe to Base64-encode a password before storing it?
No. Base64 provides no protection at all — treat a Base64-encoded secret as equivalent to plain text. Use proper password hashing (like bcrypt) or encryption instead, never Base64, for anything sensitive.